TCVN TIÊU CHUẨN QUỐC GIA

TCVN xxxx:2016
Xuất bản lần 1

GIAO THỨC INTERNET PHIÊN BẢN 6 (IPV6) - GIAO THỨC

PHÁT HIỆN ĐỐI TƯỢNG NGHE MULTICAST
Internet Protocol version 6 (IPv6) - Multicast Listener Discovery

HÀ NỘI – 2016
TCVN xxxx:2016

2
 TCVN xxxx:2016
Mục lục

1 Phạm vi áp dụng ............................................................................................................................... 7

2 Tài liệu viện dẫn ................................................................................................................................ 7

3 Thuật ngữ và định nghĩa .................................................................................................................. 7

4 Chữ viết tắt ........................................................................................................................................ 8

5 Tổng quan giao thức ........................................................................................................................ 9

5.1 Thiết lập trạng thái nghe multicast trên các đối tượng nghe địa chỉ multicast ................................. 10

5.2 Trao đổi các bản tin giữa Querier và các nút nghe ......................................................................... 11

5.3 Thiết lập trạng thái đối tượng nghe địa chỉ multicast trên router multicast ...................................... 13

6 Giao diện dịch vụ cho việc yêu cầu nhận IP Multicast ................................................................. 15

7 Trạng thái nghe multicast được duy trì bởi các nút ..................................................................... 16

7.1 Trạng thái từng socket ................................................................................................................... 16

7.2 Trạng thái từng giao diện ............................................................................................................... 16

8 Các định dạng bản tin..................................................................................................................... 18

8.1 Bản tin Multicast Listener Query .................................................................................................... 19

8.2 Bản tin Multicast Listener Report.................................................................................................... 23

9 Mô tả giao thức đối với các đối tượng nghe địa chỉ multicast .................................................... 30

9.1 Xử lý theo sự thay đổi của trạng thái từng giao diện ...................................................................... 31

9.2 Xử lý khi nhận bản tin Query .......................................................................................................... 33

9.3 Xử lý khi bộ đếm thời gian kết thúc ................................................................................................ 35

10 Mô tả của giao thức cho router multicast ................................................................................... 36

10.1 Các điều kiện cho những bản tin Query MLD ............................................................................... 37

10.2 Trạng thái MLD được duy trì bởi các router multicast .................................................................. 38

10.3 Các quy tắc chuyển tiếp nguồn MLDv2 cụ thể ............................................................................. 42

10.4 Xử lý khi nhận bản tin Report ....................................................................................................... 43

10.5 Chuyển đổi các chế độ lọc của router .......................................................................................... 46

10.6 Các xử lý khi nhận bản tin Query ................................................................................................. 46

11 Tính tương thích với MLDv1 ........................................................................................................ 48

11.1 Sự khác biệt về phiên bản của bản tin Query ............................................................................... 48

3
TCVN xxxx:2016
11.2 Cách xử lý của đối tượng nghe địa chỉ multicast .......................................................................... 48

11.3 Cách xử lý của router multicast .................................................................................................... 49

12 Danh sách các bộ đếm thời gian, bộ đếm và giá trị mặc định của chúng ................................ 50

12.1 Biến Robustness .......................................................................................................................... 50

12.2 Khoảng thời gian truy vấn ............................................................................................................ 50

12.3 Khoảng thời gian phản hồi truy vấn .............................................................................................. 51

12.4 Khoảng thời gian lắng nghe địa chỉ multicast ............................................................................... 51

12.5 Khoảng thời gian hiện diện Querier khác...................................................................................... 51

12.6 Khoảng thời gian truy vấn khi khởi động ...................................................................................... 51

12.7 Số lượng truy vấn khi khởi động .................................................................................................. 51

12.8 Khoảng thời gian truy vấn đối tượng nghe cuối cùng ................................................................... 51

12.9 Số lượng truy vấn đối tượng nghe cuối cùng ............................................................................... 52

12.10 Thời gian truy vấn đối tượng nghe cuối cùng ............................................................................. 52

12.11 Khoảng thời gian báo cáo không theo thăm dò .......................................................................... 52

12.12 Thời gian chờ cho Querier phiên bản cũ hơn ............................................................................. 52

12.13 Khoảng thời gian chờ cho host phiên bản cũ hơn ...................................................................... 53

12.14 Cấu hình các bộ đếm thời gian ................................................................................................... 53

13 Các vấn đề an toàn bảo mật ......................................................................................................... 54

13.1 Bản tin Query ............................................................................................................................... 54

13.2 Các bản tin Current State Report ................................................................................................. 55

13.3 Bản tin State Change Report ........................................................................................................ 55

Phụ lục A (quy định) Lý do thiết kế căn bản .................................................................................... 56

Phụ lục B (tham khảo) Bảng đối chiếu nội dung tương đương của TCVN và tài liệu RFC 3810.. 58

Thư mục tài liệu tham khảo ............................................................................................................... 61

4
 TCVN xxxx:2016

Lời nói đầu

TCVN xxxx:2016 được xây dựng trên cơ sở RFC 3810 (2004)

“Multicast Listener Discovery Version 2 (MLDv2) for IPv6” của
Nhóm đặc trách về kỹ thuật Internet (IETF).

TCVN xxxx:2016 do Viện Khoa học Kỹ thuật Bưu điện, Học viện
Công nghệ Bưu chính Viễn thông biên soạn, Bộ Thông tin và
Truyền thông đề nghị, Tổng cục Tiêu chuẩn Đo lường Chất
lượng thẩm định, Bộ Khoa học và Công nghệ công bố.

5
TCVN xxxx:2016

6
 TCVN xxxx:2016
T I Ê U C H U Ẩ N Q U ỐC G I A TCVN xxxx:2016

Giao thức Internet phiên bản 6 (IPv6) – Giao thức phát hiện đối
tượng nghe multicast
Internet Protocol version 6 (IPv6) - Multicast Listener Discovery

1 Phạm vi áp dụng

Tiêu chuẩn này quy định những đặc tả kỹ thuật của Giao thức phát hiện đối tượng nghe Multicast cho
IPv6.

Tiêu chuẩn này áp dụng cho các thiết bị nút IPv6 (gọi tắt là nút hoặc nút IPv6) yêu cầu hỗ trợ multicast
theo chính sách lọc nguồn, tức là các nút có nhu cầu nghe các gói tin theo một địa chỉ multicast chỉ từ
những địa chỉ nguồn cụ thể hay từ tất cả các nguồn khác trừ những địa chỉ nguồn cụ thể.

2 Tài liệu viện dẫn

Các tài liệu viện dẫn sau là cần thiết cho việc áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi
năm công bố thì áp dụng bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp
dụng phiên bản mới nhất, bao gồm cả các sửa đổi (nếu có).

TCVN 9802-1:2013, “Giao thức Internet phiên bản 6 (IPv6) – Phần 1: Quy định kỹ thuật”.

RFC 4443, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification, March 2006 (Giao thức bản tin điều khiển Internet cho IPv6)

RFC 4291, "IP Version 6 Addressing Architecture", February 2006 (Kiến trúc địa chỉ IPv6)

RFC 2711, "IPv6 Router Alert Option", October 1999 (Tùy chọn cảnh báo Router IPv6)

RFC 2461, "Neighbor Discovery for IP Version 6 (IPv6)", December 1998 (Khám phá nút mạng lân cận
cho IPv6)

RFC 2462, "IPv6 Stateless Address Autoconfiguration", December 1998 (Tự động cấu hình địa chỉ IPv6
không giữ trạng thái)

RFC 2464, "Transmission of IPv6 Packets over Ethernet Networks", December 1998 (Truyền các gói
tin IPv6 qua mạng Ethernet)

3 Thuật ngữ và định nghĩa

Tiêu chuẩn này sử dụng các thuật ngữ sau:

3.1 Nút (node)

Thiết bị thực thi IPv6.

3.2 Router

7
TCVN xxxx:2016
Nút có khả năng chuyển tiếp các gói tin IPv6 không được định địa chỉ trực tiếp cho nút mạng đó.

3.3 Host

Bất kỳ nút nào mà không phải là router.

3.4 Tầng trên (Upper layer)

Tầng giao thức ngay phía trên IPv6. Ví dụ, các giao thức truyền tải như TCP và UDP, giao thức điều
khiển như ICMP, giao thức định tuyến như OSPF và các giao thức internet hoặc giao thức tầng thấp
hơn thực thi kết nối kiểu đường hầm thông qua IPv6 như IPX, AppleTalk, hoặc chính IPv6.

3.5 Liên kết (Link)

Một phương tiện hoặc môi trường kết nối mà qua đó các nút mạng có thể kết nối với nhau tại tầng liên
kết, nghĩa là tầng ngay bên dưới IPv6 như Ethernet; các liên kết PPP; X.25, Frame Relay hoặc các
mạng ATM; và tầng Internet (hoặc tầng cao hơn) thực thi kết nối “đường hầm” như các đường hầm
qua IPv4 hoặc IPv6.

3.6 Giao diện (Interface)

Một giao tiếp của nút để gắn vào liên kết.

3.7 Địa chỉ (Address)

Một định danh tầng IPv6 cho một giao diện hoặc một nhóm giao diện.

3.8 Gói tin (Packet)

Phần mào đầu IPv6 cộng với phần dữ liệu của gói tin.

3.9 Querier (Thiết bị truy vấn)

Các router có thể gửi đi các bản tin Query.

3.10 Non-Querier (Thiết bị không phải Querier)

Router không có chức năng gửi đi các bản tin Query.

3.11 Socket

Tham số cụ thể được sử dụng để phân biệt giữa các thực thể gửi cầu IP multicast khác nhau (ví dụ,
các chương trình, các ứng dụng) trong các nút.

4 Chữ viết tắt

Chữ viết tắt Giải nghĩa Thuật ngữ tiếng anh

DAD Phát hiện địa chỉ trùng lặp Duplicate Address Detection

ICMPv6 Giao thức bản tin điều khiển cho IPv6 Internet Control Message Protocol

8
 TCVN xxxx:2016
version 6

IPv6 Giao thức Internet phiên bản 6 Internet Protocol version 6

IPX Tổng đài gói tin liên mạng Internetwork Packet Exchange

LLQC Số lượng truy vấn đối tượng nghe cuối Last Listener Query Count
cùng

LLQI Khoảng thời gian truy vấn đối tượng nghe Last Listener Query Interval
cuối cùng

LLQT Thời gian truy vấn đối tượng nghe cuối Last Listener Query Time
cùng

MLD Phát hiện đối tượng nghe multicast Multicast Listener Discovery

MLDv1 Phát hiện đối tượng nghe multicast phiên Multicast Listener Discovery
bản 1 version 1

MLDv2 Phát hiện đối tượng nghe multicast phiên Multicast Listener Discovery
bản 2 version 2

MALI Khoảng thời gian nghe địa chỉ multicast Multicast Address Listening
Interval

QQI Khoảng thời gian truy vấn của Querier Querier Query Interval

QQIC Mã khoảng thời gian truy vấn của Querier Querier Query Interval Code

OSPF Giao thức định tuyến tìm đường ngắn Open Shortest Path First
nhất

TCP Giao thức điều khiển truyền dẫn Transmission Control Protocol

UDP Giao thức dữ liệu người dùng User Datagram Protocol

5 Tổng quan giao thức

Giao thức MLD nói chung (bao gồm cả MLDv1 và MLDv2) là giao thức bất đối xứng, vì giao thức này
quy định cách xử lý riêng biệt cho các đối tượng nghe địa chỉ multicast (tức là các host và router nghe
các gói tin multicast) và các router multicast. Mục đích của MLD là cho phép router multicast xác định
những địa chỉ multicast và những nguồn có đối tượng nghe quan tâm đến các địa chỉ và nguồn này
trên mỗi liên kết trực tiếp của router. Thông tin thu thập bởi MLD được cung cấp cho giao thức định

9
TCVN xxxx:2016
tuyến multicast của router, để đảm bảo rằng các gói tin multicast được phân phối đến tất cả các liên kết
có đối tượng nghe quan tâm đến những gói tin này.

Các router multicast chỉ cần biết ít nhất một nút trên liên kết kết nối vào nó đang nghe các gói tin theo
một địa chỉ multicast cụ thể, từ một nguồn cụ thể; một router multicast không yêu cầu phải theo dõi các
yêu cầu của từng nút lân cận.

Với giao thức MLDv2, router multicast thực hiện vai trò router trên mỗi liên kết trực tiếp. Nếu một router
multicast có nhiều giao diện được kết nối vào cùng một liên kết, router đó chỉ cần thực hiện giao thức
MLDv2 trên một trong các giao diện đó. Cách xử lý của router phụ thuộc vào việc có hay không những
router multicast khác trên cùng mạng con. Nếu có nhiều router multicast trên mạng con thì sử dụng cơ
chế bầu chọn Querier để lựa chọn một router multicast duy nhất đóng vai trò là Querier. Tất cả các
router multicast trong mạng con lắng nghe các bản tin được gửi từ đối tượng nghe địa chỉ multicast và
duy trì cùng trạng thái về thông tin nghe multicast. Điều này để các router này có thể đảm nhiệm vai trò
Querier trong trường hợp Querier hiện tại xảy ra lỗi. Tuy nhiên, chỉ duy nhất một Querier gửi định kỳ
hoặc kích hoạt các bản tin Query trong mạng con, như được mô tả trong phần 10.1

Một đối tượng nghe địa chỉ multicast thực hiện vai trò đối tượng nghe trong giao thức MLDv2 trên tất
cả các giao diện hỗ trợ multicast, ngay cả khi có nhiều hơn 1 giao diện trong số các giao diện này
được kết nối vào cùng một liên kết.

5.1 Thiết lập trạng thái nghe multicast trên các đối tượng nghe địa chỉ multicast

Các giao thức tầng trên và các ứng dụng chạy trên nút nghe địa chỉ multicast sử dụng các lời gọi giao
diện dịch vụ xác định để yêu cầu tầng IP cho phép hoặc vô hiệu hóa chức năng tiếp nhận các gói tin
được gửi đến các địa chỉ multicast cụ thể. Nút giữ trạng thái nghe địa chỉ multicast cho từng socket mà
tại đó có các lời gọi giao diện dịch vụ. Ngoài trạng thái nghe multicast theo từng socket này, một nút
cũng phải duy trì và tính toán trạng thái nghe multicast cho từng giao diện của nó. Trạng thái này bao
gồm tập hợp các bản ghi, với mỗi bản ghi chứa một địa chỉ multicast IPv6, một chế độ lọc và một danh
sách nguồn. Chế độ lọc có thể là INCLUDE hoặc EXCLUDE. Trong chế độ INCLUDE, thì chỉ cho phép
nhận các gói tin có địa chỉ nguồn nằm trong danh sách nguồn gửi tới một địa chỉ multicast cụ thể.
Trong chế độ EXCLUDE, thì chỉ cho phép nhận các gói tin có địa chỉ nguồn nằm ngoài danh sách
nguồn gửi tới địa chỉ multicast cụ thể.

Đối với một giao diện cho trước, tồn tại nhiều nhất một bản ghi cho mỗi địa chỉ multicast. Trạng thái
từng giao diện này nhận được từ trạng thái từng socket, nhưng có thể khác với trạng thái từng socket
vì các socket khác nhau có sự khác biệt về các chế độ lọc và/hoặc các danh sách nguồn cho cùng địa
chỉ multicast và giao diện. Sau khi gói tin multicast được chấp nhận, việc phân phối gói tin này tới ứng
dụng phụ thuộc vào trạng thái nghe multicast của socket mà ứng dụng đó đã kết nối (và có thể cũng
phụ thuộc vào các điều kiện khác như cổng nào của tầng truyền tải mà socket sử dụng). Chú ý rằng
các bản tin MLDv2 không phụ thuộc vào việc lọc nguồn và phải luôn được xử lý bởi các host và router.

10
 TCVN xxxx:2016
5.2 Trao đổi các bản tin giữa Querier và các nút nghe

Có ba loại bản tin Query MLDv2: bản tin General Query (truy vấn thông thường), bản tin Multicast
Address Specific Query (truy vấn địa chỉ multicast cụ thể) và bản tin Multicast Address and Source
Specific Query (truy vấn địa chỉ multicast và nguồn cụ thể). Các Querier định kỳ gửi đi các bản tin
General Query để nắm bắt các thông tin về đối tượng nghe địa chỉ multicast từ một liên kết được kết
nối. Các bản tin General Query này được sử dụng để xây dựng và làm mới trạng thái của đối tượng
nghe địa chỉ multicast bên trong tất cả các router multicast trên liên kết.

Các nút phản hồi các bản tin General Query này bằng cách báo cáo lại trạng thái nghe địa chỉ multicast
từng giao diện của chúng, thông qua các bản tin Current State Report (báo cáo trạng thái hiện tại)
được gửi đến một địa chỉ multicast cụ thể mà tất cả các router trên liên kết đều lắng nghe. Mặt khác,
nếu trạng thái nghe của một nút thay đổi, nút này ngay lập tức thông báo những thay đổi này thông qua
một bản tin State Change Report (báo cáo thay đổi trạng thái). Bản tin State Change Report chứa các
Filter Mode Change Record (bản ghi thay đổi chế độ lọc) hoặc các Source List Change Record (bản ghi
thay đổi danh sách nguồn) hay các bản ghi của cả loại loại trên. Mô tả chi tiết của các bản tin Report
được trình bày ở mục 8.2.12.

Những thay đổi trạng thái của cả router và đối tượng nghe đều được thiết lập khi một bộ đếm thời gian
cụ thể kết thúc, hoặc khi nhận được một bản tin MLD (sự thay đổi trạng thái đối tượng nghe có thể
được kích hoạt bằng việc yêu cầu một lời gọi giao diện dịch vụ). Do đó, để nâng cao tính ổn định của
giao thức, để tránh sự không đáng tin cậy có thể có của việc trao đổi gói tin, các bản tin sẽ được truyền
lại nhiều lần, Hơn nữa, các bộ đếm thời gian được thiết lập để kiểm tra việc mất mát bản tin có thể có,
và để đợi việc truyền lại.

Để tránh quá tải liên kết, các bản tin General Query và Current State Report theo định kỳ không áp
dụng quy tắc này, giả định rằng thông thường các bản tin này không tạo ra sự thay đổi trạng thái và
mục đích chính của chúng là làm mới trạng thái đang tồn tại. Do đó, ngay cả khi một bản tin như vậy bị
mất, trạng thái tương ứng sẽ được làm mới trong chu trình báo cáo tiếp theo.

Trái với các bản tin Current State Report, các bản tin State Change Report được truyền lại vài lần, để
tránh chúng bị mất tại một hoặc nhiều router multicast. Số lượng của bản tin truyền lại phụ thuộc vào
biến Robustness. Biến này cho phép điều chỉnh giao thức theo sự mất mát gói tin dự kiến trên một liên
kết. Nếu một liên kết được dự kiến là mất gói (ví dụ như kết nối không dây), giá trị của biến
Robustness sẽ được tăng lên. MLD là ổn định với [biến Robustness] -1 gói tin bị mất. Tiêu chuẩn này
khuyến nghị giá trị mặc định của biến Robustness là 2.

CHÚ THÍCH: Tên các bộ đếm/biến nằm trong dấu ngoặc vuông thể hiện giá trị của các bộ đếm/biến này.

Nếu xảy ra nhiều sự thay đổi tới cùng một bản lưu trữ trạng thái từng giao diện trước khi hoàn thành
việc truyền lại tất cả các bản tin State Change Report cho thay đổi đầu tiên, thì mỗi sự thay đổi bổ sung
sẽ kích hoạt việc truyền lại một bản tin State Change Report mới ngay lập tức. Phần 9.1 trình bày
phương pháp tính toán nội dung của bản tin mới này. Những bản tin State Change Report truyền lại

11
TCVN xxxx:2016
mới sẽ được lập lịch, để đảm bảo rằng mỗi một sự thay đổi trạng thái sẽ được truyền trong ít nhất giá
trị [biến Robustness] lần.

Nếu qua bản tin State Change Report, một nút trên một liên kết thể hiện việc không còn muốn lắng
nghe một địa chỉ multicast (hoặc một nguồn) cụ thể nữa, Querier phải truy vấn các đối tượng nghe
khác của địa chỉ multicast (hoặc nguồn) này trước khi xóa địa chỉ multicast (hoặc nguồn) ra khỏi mục
lưu trữ trạng thái đối tượng nghe địa chỉ multicast và dừng truyền lưu lượng một cách phù hợp. Như
vậy, Querier gửi một bản tin Multicast Address Specific Query để xác minh rằng các nút vẫn đang lắng
nghe địa chỉ multicast cụ thể này hay không. Tương tự, Querier gửi một bản tin Multicast Address and
Source Specific Query để xác minh rằng, với một địa chỉ multicast cụ thể, có nút nào vẫn đang nghe
theo một bộ các nguồn cụ thể hay không. Mục 8.1.13 mô tả chi tiết từng loại bản tin Query này.

Cả hai bản tin “Multicast Address Specific Query” và “Multicast Address and Source Specific Query” chỉ
được gửi để đáp lại các bản tin State Change Report mà không đáp lại các bản tin Current State
Report. Sự khác biệt giữa hai loại bản tin Report này nhằm tránh cho router đối xử với tất cả các bản
tin Multicast Listener Report như những thay đổi trạng thái có khả năng xảy ra. Bằng cách này, cơ chế
rời đi nhanh của MLDv2 có thể không hiệu quả nếu bản tin State Change Report bị mất, và router chỉ
nhận được bản tin Current State Report. Tuy nhiên, nó tránh được việc xử lý gia tăng ở router và giảm
lưu lượng MLD trên liên kết.

Các nút đáp lại các bản tin Query ở trên qua bản tin Current State Report, chứa trạng thái nghe địa chỉ
multicast cho từng giao diện của chúng chỉ với các địa chỉ multicast (hoặc nguồn) được truy vấn.

Để đảm bảo tính ổn định của giao thức, tất cả các bản tin Query ngoại trừ các bản tin General Query
theo định kỳ, đều được gửi lại vài lần trong một khoảng thời gian nhất định. Số lượng bản tin truyền lại
phụ thuộc vào biến Robustness. Nếu trong khi lập lịch cho bản tin Query mới, tồn tại các bản tin Query
đang ở trạng thái chờ được truyền lại cho cùng địa chỉ multicast, thì các bản tin Query mới và các bản
tin Query đang ở trạng thái chờ phải được sáp nhập. Ngoài ra, các bản tin Report về host nhận được
đối với một địa chỉ multicast có các bản tin Query đang ở trạng thái chờ có thể ảnh hưởng tới nội dung
của các bản tin Query đó.

Tính ổn định của giao thức cũng được nâng cao bằng việc sử dụng cờ S (Ngăn chặn xử lý phía
router). Như đã mô tả ở trên, khi Querier gửi đi một bản tin Multicast Address Specific Query hoặc bản
tin Multicast Address and Source Specific Query, sẽ có những bản tin Query được lập lịch để truyền lại.
Trong bản tin Query đầu tiên, cờ S được xóa. Khi Querier gửi bản tin Query này, nó làm giảm bộ đếm
thời gian cho địa chỉ multicast (hoặc nguồn) có liên quan thành một giá trị cho trước; tương tự, bất kì
router multicast non-querier nào nhận được truy vấn cũng tự hạ thấp bộ đếm thời gian của mình thành
giá trị trên. Tuy nhiên, trong khi đợi các bản tin Query được lập lịch tiếp theo được gửi, router có thể
nhận được một bản tin Report cập nhật bộ đếm thời gian. Các bản tin Query được lập lịch vẫn phải
được gửi để đảm bảo rằng router non-querier vẫn giữ trạng thái của nó đồng bộ với Querier hiện tại
(do router non-querier có thể không nhận được truy vấn đầu tiên). Tuy nhiên, bộ đếm thời gian không
nên được hạ thấp lần nữa. Do đó, Querier thiết lập giá trị cờ S trong các bản tin Query tiếp theo.
12
 TCVN xxxx:2016
5.3 Thiết lập trạng thái đối tượng nghe địa chỉ multicast trên router multicast

Các router multicast thực thi MLDv2 (có thể là Querier hoặc không) giữ trạng thái đối tượng nghe cho
từng địa chỉ multicast đối với mỗi liên kết. Trạng thái đối tượng nghe địa chỉ multicast này bao gồm một
chế độ lọc, một bộ đếm thời gian cho chế độ lọc, và một danh sách nguồn, với bộ đếm thời gian cho
từng nguồn trong danh sách. Chế độ lọc được sử dụng để thu gọn trạng thái lắng nghe toàn diện cho
một địa multicast thành một tập bé nhất, tất cả các nút đang ở trạng thái lắng nghe đều được chú ý.
Chế độ lọc có thể thay đổi để phù hợp với việc nhận từng loại bản tin Report cụ thể, hoặc khi điều kiện
bộ đếm thời gian nào đó xuất hiện.

Một router có chế độ lọc là “INCLUDE” (chế độ bao gồm) đối với một địa chỉ multicast cụ thể trên một
giao diện nhất định nếu tất cả các đối tượng nghe trên liên kết đang theo dõi địa chỉ đó ở trong chế độ
INCLUDE. Trạng thái router được thể hiện bằng INCLUDE (A), trong đó A là danh sách các nguồn,
được gọi là “Danh sách INCLUDE” (danh sách bao gồm). Danh sách INCLUDE là một tập hợp các
nguồn mà một hay nhiều đối tượng nghe trên liên kết có yêu cầu nhận. Tất cả các nguồn từ danh sách
INCLUDE sẽ được router chuyển tiếp. Bất kỳ nguồn nào khác không nằm trong danh sách INCLUDE
sẽ bị router chặn lại.

Một nguồn có thể được thêm vào danh sách INCLUDE hiện tại nếu một đối tượng nghe có chế độ
INCLUDE gửi một bản tin Current State Report hoặc bản tin State Change Report chứa nguồn đó. Mỗi
nguồn trong danh sách INCLUDE được liên kết với một bộ đếm thời gian cho nguồn, bộ đếm này được
cập nhật bất cứ khi nào một đối tượng nghe trong chế độ INCLUDE gửi đi bản tin Report xác nhận đối
tượng nghe này vẫn đang quan tâm đến nguồn cụ thể đó. Nếu bộ đếm thời gian cho một nguồn trong
danh sách INCLUDE kết thúc, nguồn này sẽ bị xóa khỏi danh sách INCLUDE.

Bên cạnh cơ chế “rời nhóm mềm” ở trên, cũng còn một cơ chế “rời nhóm nhanh” trong MLDv2; cơ chế
này cũng dựa trên việc sử dụng các bộ đếm thời gian cho nguồn. Khi một nút trong chế độ INCLUDE
không còn nhu cầu theo dõi một nguồn cụ thể, các router multicast trên liên kết hạ thấp bộ đếm thời
gian của chúng cho nguồn đó xuống một giá trị nhất định. Querier sau đó gửi một bản tin Multicast
Address and Source Specific Query, để xác minh rằng có đối tượng nghe nào khác đang theo dõi
nguồn đó hay không. Nếu nhận được một bản tin Report cho nguồn này trước khi bộ đếm thời gian kết
thúc, thì tất cả các router trên liên kết sẽ cập nhật bộ đếm thời gian cho nguồn. Nếu không, nguồn sẽ bị
xóa khỏi danh sách INCLUDE. Việc xử lý danh sách INCLUDE theo các bản tin Report nhận được,
được chi tiết trong phần 7.4.1 và 7.4.2.

Một router sẽ có chế độ EXCLUDE (chế độ ngoại trừ) đối với một địa chỉ multicast cụ thể trên một giao
diện nhất định nếu có ít nhất một đối tượng nghe trong chế độ EXCLUDE cho địa chỉ đó trên liên kết.
Khi nhận được bản tin Report đầu tiên từ đối tượng nghe này, router sẽ thiết lập bộ đếm thời gian cho
chế độ lọc tương ứng với địa chỉ đó. Bộ đếm thời gian này được thiết lập lại mỗi khi đối tượng nghe
trong chế độ EXCLUDE xác nhận trạng thái nghe của nó qua bản tin Current State Report. Bộ đếm thời
gian này cũng được cập nhật khi một đối tượng nghe ở trong chế độ INCLUDE, thông báo thay đổi chế
độ lọc của nó qua bản tin State Change Report. Bộ đếm thời gian cho chế độ lọc kết thúc đồng nghĩa

13
TCVN xxxx:2016
với việc không còn đối tượng nghe nào nữa ở trong chế độ EXCLUDE trên liên kết. Trong trường hợp
này, router chuyển về chế độ INCLUDE cho địa chỉ multicast trên.

Khi router ở trong chế độ EXCLUDE, trạng thái của router được thể hiện bằng EXCLUDE (X,Y), trong
đó X được gọi là “Danh sách được yêu cầu” và Y được gọi là “Danh sách EXCLUDE”(danh sách ngoại
trừ). Tất cả các gói tin từ các nguồn nằm ngoài danh sách EXCLUDE, sẽ được chuyển tiếp bởi router.
Danh sách được yêu cầu không gây ảnh hưởng gì đến việc chuyển tiếp. Tuy nhiên, router phải duy trì
danh sách được yêu cầu vì hai lý do sau đây:

 Để theo dõi các nguồn mà đối tượng nghe trong chế độ INCLUDE đang lắng nghe. Điều này
nhằm đảm bảo một sự chuyển đổi liền mạch của router sang chế độ INCLUDE, khi không còn
đối tượng nghe nào trong chế độ EXCLUDE nữa. Sự chuyển đổi này sẽ không làm ngắt quãng
lưu lượng tới các đối tượng nghe trong chế độ INCLUDE cho địa chỉ multicast đó. Do đó, ở thời
điểm chuyển đổi, danh sách được yêu cầu nên chứa tập hợp các nguồn mà các nút trong chế
độ INCLUDE yêu cầu rõ ràng.

Khi router chuyển sang chế độ INCLUDE, các nguồn trong danh sách được yêu cầu sẽ chuyển
sang danh sách INCLUDE, và danh sách EXCLUDE được xóa bỏ. Trước khi thực hiện việc
chuyển tiếp này, danh sách được yêu cầu có thể chứa một dự đoán không chính xác về những
nguồn mà các đối tượng nghe trong chế độ INCLUDE đang lắng nghe– có thể quá lớn hoặc
quá nhỏ. Sự không chính xác này là do danh sách được yêu cầu có thể được sử dụng cho mục
đích khóa nhanh sẽ được mô tả dưới đây. Nếu chức năng khóa nhanh được thực hiện, vài
nguồn có thể bị xóa khỏi danh sách được yêu cầu để giảm trạng thái router. Tuy nhiên, trong
trường hợp đó bộ đếm thời gian cho chế độ lọc cũng được cập nhật. Do đó, trước khi thực hiện
chuyển đổi, các đối tượng nghe trong chế độ INCLUDE sẽ có đủ thời gian để xác nhận lại sự
quan tâm của chúng với nguồn bị loại bỏ, và xây dựng lại danh sách được yêu cầu cho phù
hợp. Giao thức đảm bảo rằng khi xảy ra chuyển đổi sang chế độ INCLUDE thì danh sách được
yêu cầu là chính xác. Chi tiết về việc chuyển đổi của router sang chế độ INCLUDE được mô tả
trong Phụ lục A3.

 Để cho phép chế độ khóa nhanh các nguồn không được khóa trước đây. Nếu router nhận được
bản tin Report chứa một yêu cầu như vậy, các nguồn có liên quan sẽ được thêm vào danh sách
được yêu cầu. Bộ đếm thời gian của chúng sẽ được thiết lập về một giá trị nhỏ nhất định, và
một bản tin Multicast Address and Source Specific Query được gửi bởi Querier để kiểm tra có
nút nào trên liên kết vẫn còn quan tâm đến những nguồn đó nữa không. Nếu không nút nào
thông báo mối quan tâm của chúng đến những nguồn cụ thể đó, bộ đếm thời gian của những
nguồn này sẽ kết thúc. Sau đó, các nguồn này được chuyển từ danh sách được yêu cầu sang
danh sách EXCLUDE. Từ thời điểm này, các nguồn trên sẽ bị router chặn lại.

Việc xử lý trạng thái router trong chế độ EXCLUDE theo các bản tin Report nhận được, được chi tiết
trong bảng 10.4.1 và 10.4.2.

14
 TCVN xxxx:2016
Các xử lý của cả router và đối tượng nghe MLDv2 được mô tả trong tiêu chuẩn này đều đảm bảo tính
tương thích ngược với các host và router MLDv1. Tính tương thích này được chi tiết trong phần 11.

6 Giao diện dịch vụ cho việc yêu cầu nhận IP Multicast

Trong hệ thống IP, một giao diện dịch vụ được sử dụng bởi các giao thức tầng trên hoặc các chương
trình ứng dụng để yêu cầu tầng IP cho phép hoặc vô hiệu hóa khả năng tiếp nhận các gói tin được gửi
tới những địa chỉ IP multicast cụ thể. Để tận dụng đầy đủ những tính năng của MLDv2, giao diện dịch
vụ IP của nút phải hỗ trợ hoạt động sau đây:

IPv6MulticastListen (socket, giao diện, địa chỉ multicast IPv6, chế độ lọc, danh sách nguồn)
Trong đó:
 “socket” là một tham số cụ thể được sử dụng để phân biệt giữa các thực thể gửi yêu cầu khác
nhau (ví dụ, các chương trình, các quy trình) trong các nút; tham số socket của các cuộc gọi hệ
thống Unix BSD là một ví dụ cụ thể.

 “Giao diện” là một bộ định danh cục bộ của giao diện mạng trên đó việc nhận địa chỉ multicast
cụ thể được cho phép hoặc vô hiệu hóa. Các giao diện có thể là vật lý (ví dụ giao diện Ethernet)
hoặc ảo (ví dụ điểm kết thúc của chuyển mạch kênh ảo Frame Relay hoặc một đường hầm IP-
trong-IP). Việc triển khai có thể cho phép thông qua một tham số giao diện “không rõ ràng” đặc
biệt, trong trường hợp đó, yêu cầu sẽ được áp dụng trên giao diện “chính” hoặc “giao diện mặc
định” của nút (có thể được xác định bởi cấu hình hệ thống). Nếu thực hiện việc tiếp nhận cùng
một địa chỉ multicast trên nhiều hơn một giao diện, IPv6MulticastListen sẽ được yêu cầu một
cách riêng biệt cho từng giao diện mong muốn.

 “Địa chỉ multicast IPv6” là một địa chỉ multicast gắn với các yêu cầu. Nếu có yêu cầu tiếp nhận
nhiều hơn một địa chỉ multicast trên một giao diện cụ thể, thì IPv6MulticastLinten sẽ được thực
hiện một cách riêng biệt cho từng địa chỉ mong muốn.

 “Chế độ lọc” có thể là INCLUDE hoặc EXCLUDE. Trong chế độ INCLUDE, chỉ các gói tin có địa
chỉ nguồn được liệt kê trong danh sách địa chỉ nguồn mới có thể gửi đến một địa chỉ multicast
cụ thể. Trong chế độ EXCLUDE, chỉ các gói tin có địa chỉ nguồn nằm ngoài danh sách địa chỉ
nguồn mới có thể gửi đến một địa chỉ multicast cụ thể.

 “Danh sách nguồn” là một danh sách không theo thứ tự (danh sách này có thể không chứa
nguồn nào) chứa những địa chỉ mà từ đó việc tiếp nhận multicast được yêu cầu hoặc từ chối,
phụ thuộc vào chế độ lọc. Việc thực thi CÓ THỂ gặp phải một số hạn chế về kích thước của
danh sách nguồn. Khi giới hạn danh sách nguồn bị vượt quá, giao diện dịch vụ có thể gặp lỗi.

Với một tập hợp socket, giao diện, và địa chỉ multicast IPv6 nhất định, chỉ duy nhất một chế độ lọc và
danh sách nguồn có thể có hiệu lực tại một thời điểm. Tuy nhiên, hoặc chế độ lọc hoặc danh sách
nguồn hoặc cả hai có thể được thay đổi bởi các yêu cầu IPv6MulticastListen tiếp theo cho cùng socket,

15
TCVN xxxx:2016
giao diện, và địa chỉ Multicast IPv6. Mỗi yêu cầu đến sau thay thế hoàn toàn bất kỳ yêu cầu nào trước
đó đối với từng socket, giao diện, và địa chỉ multicast cụ thể.

Giao thức MLDv1 không hỗ trợ các bộ lọc nguồn, và có giao diện dịch vụ đơn giản hơn, MLDv1 bao
gồm các chức năng bắt đầu lắng nghe và dừng lắng nghe để cho phép hoặc vô hiệu hóa việc nghe một
địa chỉ multicast cụ thể (từ tất cả các nguồn) trên một giao diện nhất định. Các hoạt động tương ứng
của MLDv1 trong giao diện dịch vụ mới như sau:

Chức năng bắt đầu nghe tương đương với:

IPv6MulticastListen ( socket, giao diện, địa chỉ multicast IPv6, EXCLUDE, {} )

Và Chức năng dừng lắng nghe tương đương với:

IPv6MulticastListen ( socket, giao diện, địa chỉ multiast IPv6, INCLUDE, {} )

Trong đó { } là một danh sách nguồn trống.

7 Trạng thái nghe multicast được duy trì bởi các nút

7.1 Trạng thái từng socket

Với mỗi socket mà trên đó IPv6MulticastListen được yêu cầu, nút ghi lại trạng thái nghe multicast được
mong muốn cho socket đó. Trạng thái đó bao gồm một tập hợp các bản ghi có dạng:

(giao diện, địa chỉ multicast Ipv6, chế độ lọc, địa chỉ nguồn)

Trạng thái cho từng socket đưa ra để phản hồi lại từng yêu cầu của Ipv6MulticastListen trên từng
socket như sau:

 Nếu chế độ lọc được yêu cầu là INCLUDE và danh sách nguồn được yêu cầu không chứa
nguồn nào, thì mục tương ứng với giao diện và địa chỉ multicast được yêu cầu sẽ bị xóa nếu nó
hiển thị. Nếu không có mục nào được hiển thị, yêu cầu sẽ không có tác dụng.

 Nếu chế độ lọc được yêu cầu là EXCLUDE hoặc danh sách nguồn được yêu cầu không phải là
trống, mục tương ứng với giao diện và địa chỉ multiast được yêu cầu, nếu xuất hiện sẽ được
thay đổi để chứa chế độ lọc và danh sách nguồn được yêu cầu. Nếu không có mục nào xuất
hiện, một mục mới sẽ được tạo ra, sử dụng các tham số được chỉ thị trong yêu cầu.

7.2 Trạng thái từng giao diện

Ngoài trạng thái nghe multicast từng socket, một nút cũng phải duy trì hoặc tính toán trạng thái lắng
nghe multicast cho từng giao diện của nó. Trạng thái này chứa một tập hợp các bản ghi theo dạng:

(Địa chỉ multicast IPv6, chế độ lọc, danh sách nguồn)

Chỉ duy nhất một bản ghi cho từng địa chỉ multicast tồn tại cho một giao diện nhất định. Trạng thái từng
giao diện này nhận được từ trạng thái từng socket, nhưng có thể có sự khác biệt vì các socket khác

16
 TCVN xxxx:2016
nhau có những chế độ lọc và/hoặc các danh sách nguồn khác nhau cho cùng địa chỉ multicast và giao
diện. Ví dụ, giả sử một ứng dụng hay chương trình yêu cầu hoạt động trên socket s1 như sau:

IPv6MulticastListen ( s1, i, m, INCLUDE, {a, b, c} )

yêu cầu việc đón nhận các gói tin trên giao diện i được gửi tới địa chỉ multicast m, nếu chúng đến từ
nguồn a, b hoặc c. Giả sử một ứng dụng hay chương trình khác yêu cầu hoạt động trên socket s2 như
sau:

IPv6MulticastListen ( s2, i, m, INCLUDE, {b, c, d} )

yêu cầu việc đón nhận trên cùng giao diện i những gói tin được gửi tới cùng địa chỉ multicast m, nếu
chúng đến từ nguồn b, c hoặc d. Để thỏa mãn việc đón nhận các yêu cầu của cả hai socket thì giao
diện i cần nhận được các gói tin được gửi tới địa chỉ m từ bất kỳ nguồn nào trong a, b, c hay d. Do đó,
trong ví dụ này, trạng thái lắng nghe của giao diện i cho địa chỉ multiast m có chế độ lọc INCLUDE và
danh sách nguồn {a, b, c, d}.

Sau khi một gói tin multicast được chấp nhận tại tầng IP của giao diện, việc phân phối tiếp theo của gói
tin này tới ứng dụng hay tiến trình đang lắng nghe trên một socket cụ thể phụ thuộc vào trạng thái nghe
multicast của socket (và cũng phải phù hợp với những điều kiện khác, như cổng của tầng giao vận nào
mà socket đang sử dụng). Do đó nếu gói tin đến trên giao diện i, có đích là địa chỉ multicast m, với địa
chỉ nguồn a, nó có thể được phân phối vào socket s1 mà không phải là socket s2. Chú ý rằng, bản tin
MLDv2 không phụ thuộc vào việc lọc nguồn và phải được xử lý bởi các host và router.

Việc yêu cầu lọc các gói tin dựa vào trạng thái đón nhận multicast của socket là một tính năng mới của
giao diện dịch vụ này. Giao diện dịch vụ trước đó không mô tả việc lọc dựa trên trạng thái nghe
multicast; hơn nữa, họat động bắt đầu nghe multicast trên mỗi socket chỉ đơn giản làm cho nút bắt đầu
nghe địa chỉ multicast trên một giao diện cụ thể; các gói tin được gửi tới địa chỉ multicast đó có thể
được phân phối cho tất cả các socket, dù chúng đã bắt đầu nghe hay chưa.

Quy tắc thông thường để trạng thái từng giao diện nhận được từ trạng thái từng socket như sau: với
từng cặp (giao diện, địa chỉ multicast) riêng biệt xuất hiện trong trạng thái từng socket, một bản ghi
từng giao diện được tạo ra cho địa chỉ multicast này trên giao diện đó. Tất cả các bản ghi socket chứa
cùng cặp (giao diện, địa chỉ multicast) được xem xét như sau:

 Nếu bất kỳ bản ghi socket nào có chế độ lọc là EXCLUDE thì chế độ lọc của bản ghi giao diện
là EXCLUDE, và danh sách nguồn của bản ghi giao diện là phần giao cắt của các danh sách
địa chỉ nguồn cho tất cả các bản ghi socket trong chế độ lọc EXCLUDE, trừ đi các địa chỉ nguồn
xuất hiện trong bất kỳ bản ghi socket nào có chế độ lọc INCLUDE. Ví dụ, nếu các bản ghi
socket cho địa chỉ multicast m trên giao diện i là:

từ socket s1: ( i, m, EXCLUDE, {a, b, c, d} )

từ socket s2: ( i, m, EXCLUDE, {b, c, d, e} )

từ socket s3: ( i, m, INCLUDE, {d, e, f} )

17
TCVN xxxx:2016
bản ghi giao diện tương ứng trên giao diện i là:

(m, EXCLUDE, {b, c})

Nếu socket thứ tư được thêm vào như sau:

Từ socket s4: (( i, m, EXCLUDE, { } )

bản ghi giao diện sẽ trở thành:

(m, EXCLUDE, { } )

 Nếu tất cả các bản ghi socket có một chế độ lọc là INCLUDE thì chế độ lọc của bản ghi giao
diện là INCLUDE, và danh sách nguồn của bản ghi giao diện là kết hợp của các danh sách
nguồn của tất cả các bản ghi socket. Ví dụ, nếu các bản ghi socket cho địa chỉ multicast m trên
giao diện i là:

từ socket s1: ( i, m, INCLUDE, {a, b, c} )

từ socket s2: ( i, m, INCLUDE, {b, c, d} )

từ socket s3: ( i, m, INCLUDE, {e, f} )

thì bản ghi giao diện tương ứng trên giao diện i là:

(m, INCLUDE, {a, b, c, d, e, f})

Việc thực hiện KHÔNG ĐƯỢC sử dụng bản ghi giao diện EXCLUDE cho một địa chỉ multicast nếu tất
cả các socket cho địa chỉ multicast này ở trong trạng thái INCLUDE. Nếu tài nguyên hệ thống bị giới
hạn khi tính toán danh sách nguồn cho trạng thái từng giao diện, một lỗi PHẢI được trả về giao diện đã
yêu cầu.

Các quy luật ở trên cho việc nhận biết trạng thái từng giao diện được đánh giá lại bất cứ khi nào một
yêu cầu IPv6MultiastListen làm thay đổi trạng thái từng socket bằng cách thêm vào, xóa bỏ hay chỉnh
sửa bản ghi trạng thái từng socket. Chú ý rằng một thay đổi của trạng thái từng socket không nhất thiết
dẫn đến một sự thay đổi trong trạng thái từng giao diện.

8 Các định dạng bản tin

MLDv2 là một giao thức con của ICMPv6, do đó, các dạng bản tin của MLDv2 là một tập con của các
bản tin ICMPv6, và các bản tin MLDv2 được định nghĩa trong các gói IPv6 bởi giá trị trường Next
Header bằng 58. Tất cả các bản tin MLDv2 được mô tả trong tiêu chuẩn này PHẢI được gửi với địa chỉ
nguồn link-local, trường Hop Limit có giá trị bằng 1, và tùy chọn Router Alert IPv6 [RFC2711] trong
mào đầu Hop-by-Hop Options. (tùy chọn Router Alert nhằm mục đích để các router kiểm tra các bản tin
MLDv2 được gửi tới các địa chỉ multicast IPv6 mà router không có nhu cầu.) Các bản tin Report
MLDv2 có thể được gửi với địa chỉ nguồn được thiết lập thành địa chỉ không xác định [RFC 4291], nếu
giao diện gửi không có một địa chỉ nguồn IPv6 link-local hợp lệ.

Hai loại bản tin MLD liên quan đến giao thức MLDv2 được mô tả trong tiêu chuẩn này:

18
 TCVN xxxx:2016
 Bản tin Multicast Listener Query (trường Type có giá trị bằng 130 theo hệ thập phân)

 Bản tin Multicast Listener Report phiên bản 2 (Trường Type có giá trị bằng 143 theo hệ thập
phân).

Để đảm bảo tính tương tác với các nút triển khai MLDv1 (phần 11), việc triển khai MLDv2 cũng phải hỗ
trợ hai loại bản tin sau:

o Bản tin Multicast Listener Report phiên bản 1 (Trường Type có giá trị bằng 131 theo hệ thập
phân) [RFC2710]

o Bản tin Multicast Listener Done (hoàn thành nghe multicast) phiên bản 1 (Trường Type có giá trị
bằng 132 theo hệ thập phân) [RFC2710]
Các loại bản tin không được nhận biết PHẢI được tự động bỏ qua. Các loại bản tin khác có thể được
sử dụng bởi các phiên bản hoặc các phần mở rộng MLD mới hơn, bởi các giao thức định tuyến
multicast hoặc một số phương pháp khác.

Trong phần còn lại của tiêu chuẩn này, bản tin Multicast Listener Query, bản tin Multicast Listener
Report, bản tin Multicast Listener Done được gọi tắt là bản tin Query, bản tin Report, và bản tin Done
một cách tương ứng.

8.1 Bản tin Multicast Listener Query

Các bản tin Multicast Listener Query được gửi bởi các Querier để truy vấn trạng thái nghe multicast
của các giao diện lân cận. Các bản tin Query có định dạng bản tin như sau:

19
TCVN xxxx:2016

Hình 1 - Định dạng bản tin Query

20
 TCVN xxxx:2016
8.1.1 Trường Code (Mã)
Được khởi tạo bằng 0 bởi bên gửi; được bên nhận bỏ qua.

8.1.2 Trường Checksum (kiểm tra tổng)

Trường Checksum ICMPv6 chuẩn thực hiện kiểm tra toàn bộ bản tin MLDv2, cộng thêm “mào đầu ảo”
của các trường mào đầu IPv6 [RFC 4443]. Để tính toán lỗi, trường Checksum được thiết lập bằng 0.
Khi một gói tin được gửi, trường Checksum PHẢI được xác minh trước khi xử lý gói tin đó.

8.1.3 Trường Maximum Respond Code (Mã phản hồi tối đa)

Trường Maximum Respond Code quy định thời gian cho phép tối đa trước khi gửi một bản tin Report
phản hồi. Thời gian thực tế cho phép, được gọi là trễ phản hồi tối đa, thể hiện theo đơn vị mili-giây, và
được nhận từ mã phản hồi tối đa như sau:

Nếu giá trị trường Maximum Respond Code nhỏ hơn 32768 thì trễ phản hồi tối đa bằng giá trị của
trường Maximum Respond Code.

Nếu giá trị trường Maximum Respond Code lớn hơn hoặc bằng 32768 thì trễ phản hồi tối đa bằng
[(mant | 0x1000) << (exp+3)].

Trong đó, ký hiệu mant và exp được quy định như sau:

0 1 2 3 4 5 6 7 8 9 A B C D E F
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| exp | mant |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Các giá trị nhỏ của trễ phản hồi tối đa cho phép các router MLDv2 điều chỉnh “trễ rời nhóm” (thời gian
giữa thời điểm nút cuối cùng trên liên kết dừng nghe một địa chỉ multicast cụ thể và thời điểm giao thức
định tuyến được thông báo rằng không còn một đối tượng nghe nào nữa cho địa chỉ đó). Các giá trị lớn
hơn, đặc biệt theo bậc lũy thừa, cho phép điều chỉnh sự bùng nổ của lưu lượng MLD trên một liên kết.

8.1.4 Trường Reserve (Dành trước)

Được khởi tạo bằng 0 bởi bên gửi, được bên nhận bỏ qua.

8.1.5 Trường Multicast Address (Địa chỉ Multicast)

Trong bản tin General Query, trường Multicast Address được thiết lập về 0. Trong bản tin Multicast
Address Specific Query hoặc bản tin Multicast Address and Source Specific Query, trường này được
thiết lập thành địa chỉ multicast được truy vấn.

8.1.6 Trường Resv

Được khởi tạo bằng 0 bởi bên gửi, được bên nhận bỏ qua.

8.1.7 Trường S Flag (Cờ S) - Ngăn chặn xử lý phía router

21
TCVN xxxx:2016
Khi được thiết lập bằng 1, cờ S yêu cầu bất cứ router multicast nào đang nhận bản tin ngừng cập nhật
các bộ đếm thời gian như chúng vẫn thực hiện ngay sau khi nhận được một bản tin Query. Tuy nhiên
cờ S không ngăn chặn việc bầu chọn Querier hoặc xử lý bản tin Query phía host thông thường mà
router có thể được yêu cầu thực hiện (khi router trở thành đối tượng nghe multicast).

8.1.8 Trường QRV (biến Robustness của Querier)

Nếu khác không, trường QRV chứa giá trị [biến Robustness] được sử dụng bởi Querier. Nếu [biến
Robustness] của Querier vượt quá 7 (giá trị tối đa của trường QRV), trường QRV được đặt bằng 0.

Các router nhận giá trị QRV từ bản tin Query vừa nhận được gần nhất như là giá trị [biến Robustness]
của chính nó. Nếu trường QRV vừa nhận được gần nhất bằng 0 thì router sẽ sử dụng giá trị [biến
Robustness] mặc định được quy định trong phần 12.1, hoặc một giá trị đã được cấu hình cố định.

8.1.9 Trường QQIC (Mã khoảng thời gian truy vấn của querier)

Trường QQIC quy định [khoảng thời gian truy vấn] được sử dụng bởi Querier. Khoảng thời gian thực
tế, được gọi là khoảng thời gian truy vấn của Querier (viết tắt là QQI), được thể hiện theo đơn vị giây,
và được nhận từ QQIC như sau:

Nếu QQIC < 128, giá trị khoảng thời gian truy vấn của Querier bằng giá trị của trường QQIC
Nếu QQIC >= 128, giá trị khoảng thời gian truy vấn của Querier bằng: (mant | 0x10) << (exp + 3)
Trong đó, ký hiệu exp và mant được quy định như sau:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1| exp | mant |
+-+-+-+-+-+-+-+-+

Các router multicast không phải là Querier hiện tại sẽ nhận giá trị QQI từ bản tin Query nhận được gần
nhất như là giá trị [khoảng thời gian truy vấn] của chính nó. Nếu giá trị QQI vừa nhận được bằng 0 thì
các router sẽ sử dụng giá trị [khoảng thời gian truy vấn] mặc định được quy định trong mục 12.2.

8.1.10 Number of Sources [N] (Số lượng nguồn)

Trường Number of Sources (N) quy định số lượng địa chỉ nguồn đang có mặt trong bản tin Query. Số
lượng này bằng 0 trong một bản tin General Query hoặc bản tin Multicast Address Specific Query và
khác không trong một bản tin Multicast Address and Source Specific Query. Số lượng này được giới
hạn bởi MTU của liên kết mà bản tin Query được gửi. Ví dụ, trên một liên kết Ethernet với MTU bằng
1500 octet, mào đầu IPv6 (40 octet) cùng với tùy chọn Router Alert thành 48 octet; do đó, còn lại 1424
octet cho các địa chỉ nguồn sẽ giới hạn số lượng địa chỉ nguồn bằng 89 (1424/16).

8.1.11 Source Address [i] (Địa chỉ nguồn)

Trường Source Address[i] là một véc tơ của n địa chỉ unicast, trong đó n là giá trị của trường Number
of Sources [N].

8.1.12 Dữ liệu bổ sung

22
 TCVN xxxx:2016
Nếu trường Payload Length trong mào đầu IPv6 của một bản tin Query nhận được quy định rằng sau
các trường được mô tả ở trên có xuất hiện các octet dữ liệu bổ sung, thì việc triển khai MLDv2 PHẢI
sử dụng các octet này để tính toán xác minh Checksum MLD nhận được nhưng mặt khác PHẢI bỏ qua
các octet bổ sung đó. Khi gửi một bản tin Query, việc thực thi MLDv2 KHÔNG ĐƯỢC bao gồm những
octet bổ sung sau các trường được mô tả ở trên.

8.1.13 Các biến thể của bản tin Query

Bản tin Query có ba biến thể như sau:

o “Bản tin General Query” được gửi bởi Querier để biết được những địa chỉ multicast nào có đối
tượng nghe trên một liên kết được kết nối. Trong bản tin General Query, cả trường Multicast
Address và trường Number of Sources (N) đều bằng 0

o “Bản tin Multicast Address Specific Query” được gửi bởi Querier để biết được rằng một địa chỉ
multicast cụ thể có đối tượng nghe nào trên một liên kết được kết nối hay không. Trong bản tin
Multicast Address Specific Query, trường Multicast Address chứa địa chỉ multicast đang được
theo dõi, trong khi trường Number of Sources(N) được đặt bằng 0.

o “Bản tin Multicast Address and Source Specific Query” được gửi bởi bộ Querier để biết được
rằng các nguồn từ danh sách xác định cho một địa chỉ multicast cụ thể có đối tượng nghe nào
trên một liên kết được kết nối hay không. Trong bản tin Multicast Address and Source Specific
Query, trường Multicast Address chứa địa chỉ multicast đang được theo dõi, trong khi các
trường Source Address [i] chứa các địa chỉ nguồn được theo dõi.

8.1.14 Những địa chỉ nguồn cho các bản tin Query

Tất cả các bản tin Query MLDv2 PHẢI được gửi với địa chỉ nguồn IPv6 link-local hợp lệ. Nếu một nút
nhận được bản tin Query có địa chỉ nguồn IPv6 là địa chỉ không xác định (::), hoặc các địa chỉ khác
không phải địa chỉ IPv6 hợp lệ, nút PHẢI loại bỏ tự động bản tin này và NÊN ghi lại cảnh báo.

8.1.15 Những địa chỉ đích cho các bản tin Query

Trong MLDv2, các bản tin General Query được gửi tới địa chỉ multicast tất cả các nút trong phạm vi
liên kết (FF02::1). Các bản tin Multicast Address Specific Query và bản tin Multicast Address and
Source Specific Query được gửi có địa chỉ đích là địa chỉ multicast được theo dõi. Tuy nhiên, một nút
PHẢI chấp nhận và xử lý bất kỳ bản tin Query nào có trường Destination Address chứa những địa chỉ
(unicast hoặc multicast) được gán cho giao diện mà bản tin Query tới. Điều này có thể hữu ích trong
một số trường hợp, chẳng hạn cho mục đích tìm và sửa lỗi.

8.2 Bản tin Multicast Listener Report

Các bản tin Multicast Listener Report được gửi bởi các nút IP để thông báo (tới các router lân cận)
trạng thái nghe multicast hiện tại hoặc để thay đổi trạng thái nghe multicast của các giao diện của
chúng.

23
TCVN xxxx:2016
Hình 2 trình bày định dạng của bản tin Report.

Hình 2 - Định dạng bản tin Report

24
 TCVN xxxx:2016
Mỗi Multicast Address Record (bản ghi địa chỉ multicast) trong bản tin Report có định dạng như hình 3.

Hình 3 - Định dạng Multicast Address Record (bản ghi địa chỉ multicast)

8.2.1 Trường Reserved (Dự phòng)

Trường Reserved được đặt bằng 0 khi truyền và được bên nhận bỏ qua.

25
TCVN xxxx:2016
8.2.2 Trường Checksum (Kiểm tra tổng)

Trường Checksum ICMPv6 chuẩn thực hiện kiểm tra toàn bộ bản tin MLDv2, cộng thêm “mào đầu ảo”
của trường mào đầu IPv6 [TCVN 9802-1:2013, RFC 4443]. Để tính toán kiểm tra tổng, trường
Checksum được đặt bằng 0. Khi một gói tin được nhận, trường Checksum PHẢI được xác minh trước
khi xử lý nó.

8.2.3 Trường Nr of Mcast Address Records (Số lượng các bản ghi địa chỉ Multicast M)

Trường Nr of Mcast Address Records (M) quy định số lượng các Multicast Address Record được hiển
thị trong một bản tin Report.

8.2.4 Trường Multicast Address Record (Bản ghi địa chỉ Multicast)

Mỗi Multicast Address Record là một khối các trường chứa thông tin ở máy gửi đang nghe một địa chỉ
multicast đơn lẻ trên giao diện mà từ đó bản tin Report được gửi.

8.2.5 Trường Record Type (Loại bản ghi)

Trường này quy định loại Multicast Address Record. Xem mục 8.2.12 về các mô tả chi tiết cho các loại
bản ghi khả dụng khác nhau.

8.2.6 Trường Aux Data Len (Chiều dài dữ liệu bổ trợ)

Trường Aux Data Len chứa chiều dài của trường dữ liệu bổ trợ trong Multicast Address Record, theo
đơn vị từ 32-bit. Nó có thể bằng 0 nhằm thể hiện không có dữ liệu bổ trợ nào.

8.2.7 Trường Number of Sources [N] (Số lượng Nguồn)

Trường Number of Sources quy định số lượng địa chỉ nguồn được hiển thị trong Multicast Address
Record.

8.2.8 Trường Multicast Address (Địa chỉ multicast)

Trường Multicast Address chứa địa chỉ multicast của Multicast Address Record.

8.2.9 Trường Source Address [i] (Địa chị Nguồn)

Các trường Source Address là một véc tơ của n các địa chỉ unicast, trong đó n là giá trị của trường
Number of Sources (N) trong bản ghi.

8.2.10 Trường Auxiliary Data (Dữ liệu bổ trợ)

Nếu xuất hiện, trường Auxiliary Data chứa các thông tin bổ sung liên quan đến Multicast Address
Record này. Giao thức MLDv2 quy định trong tiêu chuẩn này, không định nghĩa bất kỳ dữ liệu bổ trợ
nào. Do đó, những sự thực thi MLDv2 KHÔNG ĐƯỢC bao gồm bất kỳ dữ liệu bổ trợ (tức là, PHẢI thiết
lập trường Aux Data Len bằng 0) trong bất kỳ Multicast Address Record được truyền nào, và PHẢI bỏ
qua những dữ liệu như vậy nếu chúng xuất hiện trong Multicast Address Record nhận được. Nội dung
và mã hóa nội bộ của trường Auxiliary Data được định nghĩa bởi các phiên bản hoặc phần mở rộng
của MLD trong tương lai sẽ sử dụng trường này.

26
 TCVN xxxx:2016
8.2.11 Dữ liệu bổ sung

Nếu trường Payload Length trong mào đầu IPv6 của bản tin Report nhận được chỉ thị rằng sau
Multicast Address Record cuối cùng có những octet dữ lệu bổ sung thì các thực thi MLDv2 PHẢI sử
dụng các octet đó trong việc tính toán xác minh trường Checksum MLD nhận được nhưng mặt khác
PHẢI bỏ qua các octet bổ sung đó. Khi gửi một bản tin Report, thực thi MLD KHÔNG ĐƯỢC chứa các
octet bổ sung sau Multicast Address Record cuối cùng.

8.2.12 Các loại Multicast Address Record

Bản tin Report có thể có một số loại Multicast Address Record khác nhau như sau:

 Current State Record (bản ghi trạng thái hiện tại) được một nút gửi đi để phản hồi lại bản tin
Query nhận được trên một giao diện. Bản tin Report chứa bản ghi này thông báo trạng thái lắng
nghe hiện tại của giao diện đã nhận bản tin Query, đối với một địa chỉ multicast. Trường Record
Type của Current State Record có thể là một trong hai giá trị sau:

Giá trị Tên và Ý nghĩa

1 MODE_IS_INCLUDE – quy định rằng giao diện có chế độ lọc là INCLUDE cho
một địa chỉ multicast cụ thể. Các trường Source Address [i] trong Multicast
Address Record là danh sách nguồn của giao diện cho một địa chỉ multicast cụ
thể. Bản ghi MODE_IS_INCLUDE không bao giờ được gửi với một danh sách
nguồn trống.

2 MODE_IS_EXCLUDE – quy định rằng giao diện có chế độ lọc là EXCLUDE cho
một địa chỉ multicast cụ thể. Các trường Source Address [i] trong Multicast
Address Record nếu có sẽ là danh sách nguồn của giao diện cho địa chỉ multicast
cụ thể.

 Filter Mode Change Record (bản ghi thay đổi chế độ lọc) được gửi bởi một nút bất cứ khi nào
một yêu cầu cục bộ IPv6MulticastListen gây ra một thay đổi về chế độ lọc của bản ghi trạng thái
giao diện cho một địa chỉ multicast cụ thể (tức là thay đổi từ INCLUDE sang EXCLUDE, hoặc từ
EXCLUDE sang INCLUDE), để xác minh danh sách nguồn có thay đổi cùng thời điểm hay
không. Bản tin Report chứa bản ghi này được gửi đi từ giao diện mà thay đổi xảy ra. Trường
Record Type của Filter Mode Change Record có thể là một trong hai giá trị sau:

Giá trị Tên và ý nghĩa

3 CHANGE_TO_INCLUDE_MODE – quy định rằng giao diện được thay đổi sang chế
độ lọc INCLUDE cho một địa chỉ multicast cụ thể. Các trường Source Address [i]
trong Multicast Address Record nếu có sẽ là danh sách nguồn mới của giao diện
đối với một địa chỉ multicast cụ thể.

27
TCVN xxxx:2016

4 CHANGE_TO_EXCLUDE_MODE – quy định rằng giao diện được thay đổi sang
chế độ lọc EXCLUDE cho một địa chỉ multicast cụ thể. Trường Source Address [i]
trong Multicast Address Record nếu có sẽ là danh sách nguồn mới của giao diện
đối với địa chỉ multicast cụ thể.

 Source List Change Record (bản ghi thay đổi danh sách nguồn) được gửi bởi một nút bất cứ
khi nào một yêu cầu IPv6MulticastListen cục bộ gây ra một sự thay đổi danh sách nguồn, điều
đó không có nghĩa là thay đổi chế độ lọc của một bản ghi trạng thái giao diện cho một địa chỉ
multicast cụ thể. Bản ghi này chứa trong bản tin Report được gửi từ giao diện đã xảy ra thay
đổi. Trường Record Type của Source List Change Record có thể là một trong hai giá trị sau:

Giá trị Tên và Ý nghĩa

5 ALLOW_NEW_SOURCE – quy định rằng các trường Source Address [i] trong
Multicast Address Record này chứa một danh sách nguồn bổ sung mà nút mong
muốn lắng nghe các gói tin cho một địa chỉ multicast cụ thể. Nếu thay đổi xảy ra
tại danh sách nguồn INCLUDE, đây là những địa chỉ được thêm vào danh sách,
nếu thay đổi xảy ra tại danh sách nguồn EXCLUDE, đây là những địa chỉ được
xóa khỏi danh sách

6 BLOCK_OLD_SOURCE – quy định rằng các trường Source Address [i] trong
Multicast Address Record này chứa một danh sách các nguồn mà nút không còn
mong muốn lắng nghe các gói tin cho một địa chỉ multicast cụ thể. Nếu thay đổi
sang danh sách nguồn INCLUDE, đây là những địa chỉ đã được xóa khỏi danh
sách, nếu thay đổi sang danh sách nguồn EXCLUDE, đây là những địa chỉ được
thêm vào danh sách

Nếu sự thay đổi danh sách nguồn dẫn đến cả việc cho phép các nguồn mới và xóa các nguồn cũ, thì
hai bản ghi địa chỉ nguồn multicast sẽ được gửi với cùng địa chỉ multicast, một bản cho loại
ALLOW_NEW_SOURCES, một cho loại BLOCK_OLD_SOURCES.

Khái niệm State Change Record được sử dụng để tham chiếu đến hoặc Filter Mode Change Record
hoặc Source List Change Record.

Những biểu diễn sau được sử dụng để mô tả nội dung của Multicast Address Record liên quan đến
một địa chỉ multicast cụ thể:

IS_IN ( x ) - Loại bản ghi là MODE_IS_INCLUDE, các địa chỉ nguồn x

IS_EX ( x ) - Loại bản ghi là MODE_IS_EXCLUDE, các địa chỉ nguồn x

TO_IN ( x ) - Loại bản ghi làCHANGE_TO_INCLUDE_MODE, các địa chỉ nguồn x

TO_EX ( x ) - Loại bản ghi là CHANGE_TO_EXCLUDE_MODE, các địa chỉ nguồn x

28
 TCVN xxxx:2016
ALLOW ( x ) - Loại bản ghi là ALLOW_NEW_SOURCES, các địa chỉ nguồn x

BLOCK ( x ) - Loại bản ghi là BLOCK_OLD_SOURCES, các địa chỉ nguồn x

Trong đó x là:
 Chữ viết hoa (ví dụ “A”) đại diện cho một tập các địa chỉ nguồn
hoặc
 Biểu diễn nhiều tập hợp các địa chỉ nguồn (ví dụ “A+B”) trong đó, “A+B” có nghĩa là tập hợp kết
hợp giữa A và B, “A*B” có nghĩa là phần giao giữa A và B, “A-B” có nghĩa là loại bỏ tất cả các
thành phần của tập B từ tập A.

8.2.13 Các địa chỉ nguồn cho bản tin Report

Một bản tin Report MLDv2 PHẢI được gửi với một địa chỉ IPv6 link-local hợp lệ, hoặc địa chỉ không xác
định (::) nếu giao diện gửi không yêu cầu địa chỉ link-local hợp lệ. Các bản tin Report gửi đi với địa chỉ
không xác định để hỗ trợ việc sử dụng IP multicast trong giao thức phát hiện nút mạng lân cận [RFC
2461]. Với giao thức tự động cấu hình địa chỉ phi trạng thái [được định nghĩa trong RFC2462], một nút
được yêu cầu tham gia nhiều nhóm multicast IPv6 khác nhau để thực hiện chức năng phát hiện địa chỉ
trùng (DAD). Trước khi thực hiện DAD, địa chỉ duy nhất mà nút báo cáo sử dụng cho việc gửi là một
địa chỉ thăm dò, không thể được sử dụng cho truyền thông. Do đó, địa chỉ không xác định phải được
sử dụng.

Mặt khác, router PHẢI tự động bỏ qua những gói tin không có địa chỉ link-local hợp lệ, mà không tác
động đến nội dung của các gói tin đó. Do đó, một bản tin Report sẽ bị bỏ qua nếu router không xác
định được địa chỉ nguồn của gói tin thuộc về liên kết được kết nối với giao diện nhận gói tin đó. Bản tin
Report được gửi với địa chỉ không xác định cũng bị router loại bỏ. Điều này giúp tăng cường bảo mật,
vì các nút báo cáo không xác định sẽ không thể làm ảnh hưởng đến trạng thái các router MLDv2. Tuy
nhiên, nút báo cáo đã thay đổi trạng thái nghe của mình đối với các địa chỉ multicast được chứa trong
Multicast Address Record của bản tin Report. Từ thời điểm này, nút báo cáo sẽ xử lý các gói tin được
gửi tới các địa chỉ multicast đó theo trạng thái nghe mới này. Khi địa chỉ link-local là hợp lệ, nút NÊN
phát đi các bản tin Report MLDv2 mới cho tất cả các địa chỉ multicast đã tham gia trên giao diện.

8.2.14 Địa chỉ đích của các bản tin Report

Các bản tin Report phiên bản 2 được gửi với địa chỉ IP đích là FF02:0:0:0:0:0:0:16 (địa chỉ mà tất cả
các router multicast MLDv2 có khả năng nghe). Một nút hoạt động trong chế độ tương thích với phiên
bản 1 gửi các bản tin Report phiên bản 1 tới địa chỉ multicast được xác định trong trường Multicast
Address của bản tin Report. Ngoài ra, một nút PHẢI chấp nhận và xử lý bất kỳ bản tin Report phiên bản
1 nào có trường Destination Address chứa địa chỉ IPv6 (unicast hoặc multicast) được chỉ định cho giao
diện mà bản tin Report đó đến. Điều này là hữu ích cho một số mục đích như tìm và sửa lỗi.

8.2.15 Kích thước bản tin Report

29
TCVN xxxx:2016
Nếu tập hợp các Multicast Address Record được yêu cầu trong bản tin Report không phù hợp với giới
hạn kích thước của bản tin Report (được xác định theo MTU của liên kết mà nó sẽ được gửi) thì các
Multicast Address Record cần được gửi trong nhiều bản tin Report để báo cáo toàn bộ các bản ghi.

Nếu một Multicast Address Record chứa quá nhiều địa chỉ nguồn do đó bản ghi này không phù hợp với
giới hạn kích thước của bản tin Report thì:

o Nếu loại bản ghi không phải là IS_EX hoặc là TO_EX, bản ghi đó sẽ được chia thành nhiều
Multicast Address Record; mỗi bản ghi như vậy chứa một tập con khác nhau của các địa chỉ
nguồn và sẽ được gửi trong các bản tin Report riêng biệt.

o Nếu loại bản ghi là IS_EX hoặc là TO_EX, một Multicast Address Record đơn lẻ được gửi với
nhiều địa chỉ nguồn nhất có thể; các địa chỉ nguồn còn lại sẽ không được báo cáo. Mặc dù lựa
chọn địa chỉ nguồn nào để báo cáo là tùy ý, tiêu chuẩn này khuyến nghị báo cáo một tập hợp
giống nhau các nguồn trong mỗi bản tin Report tiếp theo.

9 Mô tả giao thức đối với các đối tượng nghe địa chỉ multicast

MLDv2 là giao thức bất đối xứng, vì giao thức này quy định rõ ràng các cách xử lý riêng biệt cho các
đối tượng nghe địa chỉ multicast (các host và router lắng nghe các gói tin multicast) và các router
multicast. Phần này mô tả chức năng của MLDv2 áp dụng cho tất cả các đối tượng nghe địa chỉ
multicast. (Chú ý rằng một router multicast cũng là một đối tượng nghe multicast thực hiện cả hai chức
năng của MLDv2; nó nhận và phản hồi lại các bản tin MLD của chính mình, cũng như các bản tin MLD
của các nút mạng lân cận nó.) Chức năng router của MLDv2 được mô tả trong phần 10.

Trong phần này, một nút thực hiện giao thức trên tất cả các giao diện hỗ trợ việc tiếp nhận multicast,
ngay cả khi có nhiều hơn một giao diện kết nối trên cùng liên kết.

Để hoạt động tương tác với các router multicast đang chạy giao thức MLDv1, các nút duy trì biến Host
Compatibility Mode (biến chế độ tương thích host) cho mỗi giao diện mà việc tiếp nhận multicast được
hỗ trợ. Phần này mô tả việc xử lý của các nút nghe địa chỉ multicast trên các giao diện mà Host
Compatibility Mode = MLDv2. Giải thuật để xác định biến Host Compatibility Mode và cách xử lý nếu
giá trị của biến này được thiết lập là MLDv1, được mô tả trong phần 11.

Địa chỉ multicast tất cả các nút trong phạm vi liên kết (FF02::1) được xử lý như một trường hợp đặc
biệt. Trên tất cả các nút - tức là tất cả các host và router bao gồm cả các router multicast – việc lắng
nghe các gói tin có đích là địa chỉ multicast tất cả các nút từ tất cả các nguồn, được cho phép trên tất
cả các giao diện mà việc nghe multicast được hỗ trợ. Không có bản tin MLD nào được gửi mà không
liên quan đến địa chỉ multicast tất cả các nút trong phạm vi liên kết hoặc cũng không phải là địa chỉ
multicast có giới hạn bằng 0 (dự phòng) hoặc 1 (node-local).

Có 3 loại sự kiện có thể kích hoạt các hoạt động của giao thức MLDv2 trên 1 liên kết:
 Thay đổi của trạng thái nghe từng giao diện, được gây ra bởi yêu cầu cục bộ
IPv6MulticastListen

30
 TCVN xxxx:2016
 Bắt đầu một bộ đếm thời gian cụ thể

 Tiếp nhận một bản tin Query

(Các bản tin MLD nhận được không phải là bản tin Query sẽ được tự động bỏ qua, trừ khi chúng được
sử dụng cho việc tương tác với các nút thực thi MLDv1)

Các phần tiếp theo mô tả các hoạt động được thực hiện cho từng trường hợp. Tên các bộ đếm thời
gian và bộ đếm, giá trị mặc định cho các bộ đếm thời gian và bộ đếm đó được quy định trong phần 12.

9.1 Xử lý theo sự thay đổi của trạng thái từng giao diện

Yêu cầu IPv6MulticastListen có thể gây ra sự thay đổi trạng thái nghe multicast của một giao diện, theo
các quy tắc trong phần 7.2. Mỗi một thay đổi như vậy ảnh hướng đến bản ghi từng giao diện đối với
một địa chỉ multicast đơn lẻ.

Một thay đổi của trạng thái từng giao diện buộc nút phải ngay lập tức truyền đi bản tin State Change
Report từ giao diện đó. Loại và nội dung của các Multicast Address Record trong bản tin Report đó
được xác định bằng cách so sánh chế độ lọc và danh sách nguồn cho địa chỉ multicast bị ảnh hưởng
trước và sau thay đổi, theo bảng dưới đây. Nếu thay đổi là việc tạo ra một bản ghi từng giao diện mới
hoặc thay đổi là việc xóa bản ghi từng giao diện, thì Multicast Address Record này được xem là có chế
độ lọc INCLUDE và danh sách nguồn trống.

Trạng thái cũ Trạng thái mới Bản ghi State Change Record được gửi
------------------ -------------------- ------------------------------------------------------
INCLUDE (A) INCLUDE (B) ALLOW (B-A), BLOCK (A-B)

EXCLUDE (A) EXCLUDE (B) ALLOW (A-B), BLOCK (B-A)

INCLUDE (A) EXCLUDE (B) TO_EX (B)

EXCLUDE (A) INCLUDE (B) TO_IN (B)

Nếu danh sách nguồn được tính toán cho State Change Record ALLOW hoặc BLOCK là trống, bản ghi
đó được bỏ qua khỏi bản tin Report.

Để chắc chắn rằng bản tin State Change Report không bị mất bởi một hay nhiều router multicast thì
([biến Robustness] -1) bản tin này sẽ được lập lịch để truyền lại, qua bộ đếm thời gian truyền lại, ở
khoảng thời gian được chọn ngẫu nhiên trong khoảng (0, [khoảng thời gian báo cáo không theo thăm
dò]).

Nếu xảy ra thêm nhiều thay đổi tới cùng một bản ghi trạng thái từng giao diện trước khi hoàn thành
việc truyền lại tất cả các bản tin State Change Reportcho thay đổi đầu tiên, mỗi thay đổi bổ sung như
vậy sẽ kích hoạt việc truyền ngay lập tức một bản tin State Change Report mới.

Nội dung của bản tin Report mới được tính toán như sau:
o Với bản tin Report đầu tiên, trạng thái từng giao diện cho địa chỉ multicast bị tác động trước và
sau thay đổi cuối cùng sẽ được so sánh.

31
TCVN xxxx:2016
o Bản ghi thể hiện sự khác nhau được xây dựng theo bảng ở trên. Tuy nhiên, các bản ghi này
không được truyền trong 1 bản tin riêng biệt, mà thay vào đó chúng được sáp nhập với nội
dung của bản tin Report đang ở trạng thái chờ để tạo ra một bản tin State Change Report mới.
Các quy tắc cho việc tính toán bản tin Report được sáp nhập này được mô tả dưới đây.

Việc truyền bản tin State Change Report được sáp nhập sẽ chấm dứt việc truyền lại các bản tin State
Change Report trước đó cho cùng địa chỉ multicast, và trở thành bản đầu tiên của [biến Robustness]
bản tin State Change Report mới được truyền lại. Những bản tin được lặp lại này cần thiết để chắc
chắn rằng mỗi một thay đổi trạng thái này được truyền lại ít nhất [biến Robustness] lần.

Mỗi lần một nguồn trong một bản tin Report khác được tính toán ở trên, trạng thái truyền lại cho nguồn
đó cần được duy trì cho đến khi [biến Robustness] bản tin State Change Report được nút gửi đi. Điều
này được thực hiện để chắc chắn rằng một chuỗi các thay đổi trạng thái thành công không phá vỡ tính
ổn định của tiêu chuẩn. Các nguồn trong trạng thái truyền lại có thể được giữ trong danh sách truyền
lại với từng địa chỉ multicast, với một bộ đếm truyền lại cho nguồn được liên kết tới mỗi nguồn trong
danh sách. Khi một nguồn nằm trong danh sách, bộ đếm của nó được thiết lập bằng [biến
Robustness]. Mỗi lần bản tin State Change Report được gửi, bộ đếm này sẽ giảm 1 đơn vị. Khi bộ đếm
tiến về 0, nguồn sẽ bị xóa khỏi danh sách truyền lại đối với địa chỉ multicast đó.

Nếu thay đổi trạng thái nghe cho từng giao diện tạo ra một bản tin Report mới, là một thay đổi chế độ
lọc thì [biến Robustness] bản tin State Change Report tiếp theo sẽ chứa một Filter Mode Change
Record. Điều này áp dụng ngay cả khi có những thay đổi danh sách nguồn xảy ra trong chu kỳ trước
đó. Nút phải duy trì trạng thái truyền lại cho địa chỉ multicast cho đến khi [biến Robustness] bản tin
State Change Report được gửi. Điều này có thể được thực hiện thông qua một bộ đếm truyền lại chế
độ lọc cho từng địa chỉ multicast. Khi chế độ lọc thay đổi, bộ đếm được đặt về [biến Robustness]. Mỗi
lần một bản tin State Change Report được gửi, bộ đếm sẽ giảm 1 đơn vị. Khi bộ đếm tiến về 0, tức là
[biến Robustness] bản tin State Change Report với các Filter Mode Change Record được truyền sau
khi thay đổi chế độ lọc cuối cùng, và nếu các thay đổi danh sách nguồn dẫn đến các bản tin Report bổ
sung được lập lịch thì bản tin State Change Report tiếp theo sẽ bao gồm các Source List Change
Record.

Mỗi lần thay đổi trạng thái nghe cho từng giao diện tạo ra việc truyền ngay lập tức một bản tin State
Change Report mới, nội dung của bản tin Report sẽ được xác định như sau. Nếu bản tin Report chứa
Filter Mode Change Record, tức là bộ đếm truyền lại chế độ lọc cho địa chỉ multicast đó có giá trị lớn
hơn 0, và nếu chế độ lọc hiện tại của giao diện là INCLUDE thì bản tin Report sẽ chứa một bản ghi
TO_IN; nếu không thì bản tin này sẽ chứa bản ghi TO_EX. Nếu bản tin Report chứa các Source List
Change Record, tức là bộ đếm truyền lại chế độ lọc cho địa chỉ multicast bằng 0, thì bản tin Report sẽ
chứa một bản ghi ALLOW và một bản ghi BLOCK. Nội dung của các bản ghi này được xây theo bảng
sau đây:

32
 TCVN xxxx:2016
Bản ghi Các nguồn được bao gồm
---------- -----------------------------------
TO_IN Tất cả các nguồn trong trạng thái từng giao diện hiện tại phải được chuyển tiếp

TO_EX Tất cả các nguồn trong trạng thái từng giao diện hiện tại phải được chặn

ALLOW Tất cả các nguồn có trạng thái truyền lại (tất cả các nguồn từ danh sách truyền
lại) phải được chuyển tiếp

BLOCK Tất cả các nguồn có trạng thái truyền lại phải được chặn

Nếu danh sách nguồn được tính toán cho một trong hai bản ghi ALLOW hoặc bản ghi BLOCK là trống,
bản ghi đó được loại bỏ khỏi bản tin State Change Report.

Chú ý rằng: Khi bản tin State Change Report đầu tiên được gửi, bản tin Report đang chờ để sáp nhập
với bản tin này có thể được đối xử như là một bản tin Source Change Report với các bản ghi ALLOW
và BLOCK là trống (không có nguồn nào có trạng thái truyền lại).

Việc thiết lập bản tin State Change Report đã lên lịch, được kích hoạt bằng cách bật bộ đếm thời gian
truyền lại, thay vì thay đổi trạng thái nghe cho từng giao diện, đươc mô tả trong phần 9.3.

9.2 Xử lý khi nhận bản tin Query

Sau khi nhận được bản tin Query MLD, nút kiểm tra địa chỉ nguồn của bản tin có phải địa chỉ link-local
hợp lệ không, trường Hop Limit có được thiết lập bằng 1 và tùy chọn Router Alert có được thể hiện
trong mào đầu các Hop-by-Hop Options của gói tin IPv6 hay không. Nếu bất kỳ kiểm tra nào có lỗi, gói
tin sẽ bị loại bỏ.

Nếu tính hợp lệ của bản tin MLD được xác minh, nút bắt đầu xử lý bản tin Query. Thay vì phản hồi
ngay lập tức, nút làm trễ phản hồi của nó theo một khoảng thời gian ngẫu nhiên, được giới hạn bởi giá
trị trễ phản hồi tối đa nhận được từ trường Maximum Response Code trong bản tin Query nhận được.
Một nút có thể nhận nhiều bản tin Query trên các giao diện khác nhau và theo nhiều loại khác nhau (ví
dụ như bản tin General Query, bản tin Multicast Address Specific Query hay bản tin Multicast Address
and Source Specific Query), mỗi loại có thể yêu cầu trễ phản hồi riêng.

Trước khi lập lịch để phản hồi lại một bản tin Query, đầu tiên nút phải xem xét các phản hồi được lập
lịch đang ở trạng thái chờ trước đó và trong nhiều trường hợp phải lập lịch cho một phản hồi kết hợp.
Do đó, với mỗi giao diện mà nút đảm nhiệm chức năng đối tượng nghe của giao thức MLDv2, nút phải
có khả năng duy trì trạng thái như sau:

 Bộ đếm thời gian của giao diện cho việc lập lịch các phản hồi lại những bản tin General Query

 Bộ đếm thời gian của địa chỉ multicast cho việc lập lịch các phản hồi lại những bản tin Multicast
Address Specific Query (hoặc bản tin Multicast Address and Source Specific Query), cho từng
địa chỉ multicast mà nút phải báo cáo lại;

33
TCVN xxxx:2016
 Danh sách các nguồn cho từng địa chỉ multicast được báo cáo để phản hồi lại bản tin Multicast
Address and Source Specific Query

Khi một bản tin General Query hợp lệ mới đến trên một giao diện, nút kiểm tra có bản ghi trạng thái
nghe cho từng giao diện nào để báo cáo hay không. Tương tự, khi một bản tin Multicast Address
Specific Query (bản tin Multicast Address and Source Specific Query) hợp lệ mới đến trên một giao
diện, nút phải kiểm tra có bản ghi trạng thái nghe cho từng giao diện tương ứng với địa chỉ multicast
(và nguồn) được truy vấn hay không. Nếu có, trễ cho việc phản hồi được lựa chọn ngẫu nhiên trong
khoảng (0, [trễ phản hồi tối đa]), trong đó trễ phản hồi tối đa nhận được từ trường Maximum Response
Code trong bản tin Query nhận được. Các quy tắc sau được sử dụng để xác định rằng bản tin Report
cần được lập lịch hay không, và cần lập lịch loại bản tin Report nào. (Các quy tắc được xem xét theo
thứ tự và chỉ có quy tắc phù hợp đầu tiên được áp dụng).

1. Nếu có một phản hồi đang ở trạng thái chờ cho bản tin General Query trước đó được lập lịch
sớm hơn trễ được chọn, thì không cần lập lịch bất kỳ hồi đáp bổ sung nào.

2. Nếu bản tin Query nhận được là bản tin General Query thì bộ đếm thời gian của giao diện được
sử dụng để lập lịch cho bản tin hồi đáp lại bản tin General Query ngay sau trễ được lựa chọn.
Bất kỳ phản hồi đang ở trạng thái chờ nào trước đó cho bản tin General Query đều bị hủy bỏ.

3. Nếu bản tin Query nhận được là bản tin Multicast Address Specific Query hoặc bản tin Multicast
Address and Source Specific Query và không có phản hồi đang ở trạng thái chờ nào cho bản
tin Query trước đó về địa chỉ multicast này thì bộ đếm thời gian của địa chỉ multicast được sử
dụng để lập lịch bản tin Report. Nếu bản tin Query nhận được là bản tin Multicast Address and
Source Specific Query, danh sách các nguồn được yêu cầu được lưu để sử dụng khi phát đi
phản hồi.

4. Nếu có 1 phản hồi đang ở trạng thái chờ cho bản tin Query trước đó được lập lịch cho địa chỉ
multicast này, và bản tin Query mới là bản tin Multicast Address Specific Query hoặc danh sách
nguồn được lưu liên quan tới địa chỉ multicast này là trống, thì danh sách nguồn cho địa chỉ
multicast được xóa và một phản hồi duy nhất được lập lịch, sử dụng bộ đếm thời gian của địa
chỉ multicast. Phản hồi mới được lập lịch để gửi đi tại thời gian nhỏ hơn giữa thời gian còn lại
cho bản tin Report đang chờ xử lý và trễ đã được chọn.

5. Nếu bản tin Query nhận được là bản tin Multicast Address and Source Specific Query và tồn tại
một phản hồi đang ở trạng thái chờ cho địa chỉ multicast này với danh sách nguồn không trống,
thì danh sách địa chỉ nguồn multicast được mở rộng để chứa danh sách các nguồn trong bản
tin Query mới và phản hồi được lập lịch, sử dụng bộ đếm thời gian địa chỉ multicast. Phản hồi
mới được lập lịch để gửi đi tại thời gian nhỏ hơn giữa thời gian còn lại cho bản tin Report đang
chờ xử lý và trễ đã được chọn.

34
 TCVN xxxx:2016
9.3 Xử lý khi bộ đếm thời gian kết thúc

Có nhiều bộ đếm thời gian sẽ gây ra các tác động lên nút đối tượng nghe địa chỉ multicast MLD khi nó
kết thúc. Tất cả các tác động này liên quan đến các bản tin Report đang chờ xử lý được lập lịch ở nút.

1. Nếu bộ đếm thời gian của giao diện kết thúc (tức là có một phản hồi đang ở trạng thái chờ cho
bản tin General Query), thì một Current State Record được gửi cho từng địa chỉ multicast mà
một giao diện cụ thể đang nghe, như mục 7.2. Current State Record mang địa chỉ multicast và
chế độ lọc có liên quan của nó (MODE_IS_INCLUDE hoặc MODE_IS_EXCLUDE) cùng danh
sách nguồn. Nhiều Current State Record được đóng gói trong các bản tin Report riêng lẻ đến
một mức độ lớn nhất có thể.

Thuật toán này có thể dẫn đến việc bùng nổ các gói tin khi một nút lắng nghe một lượng lớn các
địa chỉ multicast. Thay vì sử dụng bộ đếm thời gian của giao diện, việc thực thi được khuyến
nghị truyền những bản tin Report như vậy trong khoảng thời gian (0, [trễ phản hồi tối đa]). Chú
ý rằng bất kỳ việc thực thi nào như vậy đều KHÔNG ĐƯỢC gửi đi một bản tin Report ngay sau
khi nhận được bản tin General Query.

2. Nếu bộ đếm thời gian của địa chỉ multicast kết thúc và danh sách các địa chỉ nguồn được ghi
cho địa chỉ multicast đó là trống (tức là, có một phản hồi đang ở trạng thái chờ cho bản tin
Multicast Address Specific Query), sau đó nếu và chỉ nếu giao diện đang có trạng thái nghe cho
địa chỉ multicast đó, thì một Current State Record sẽ được gửi cho địa chỉ đó. Current State
Record này mang địa chỉ multicast và chế độ lọc có liên quan của nó (MODE_IS_INCLUDE
hoặc MODE_IS_EXCLUDE) và danh sách nguồn.

3. Nếu bộ đếm thời gian của địa chỉ multicast kết thúc và danh sách nguồn đã được ghi cho địa
chỉ multicast đó không phải là rỗng (tức là có một phản hồi đang ở trạng thái chờ cho bản tin
Multicast Address and Source Specific Query), thì nếu và chỉ nếu giao diện có trạng thái nghe
cho địa chỉ multicast đó, thì các nội dung của Current State Record tương ứng sẽ được xác
định từ trạng thái từng giao diện và bản ghi phản hồi đang ở trạng thái chờ, như được quy định
trong bảng sau đây:

Trạng thái cho từng giao Tập hợp các nguồn trong bản ghi Current State
diện phản hồi đang ở trạng thái chờ Record

--------------------------------- --------------------------------------------------- ---------------------------

INCLUDE (A) B IS_IN (A*B)

EXCLUDE (A) B IS_IN (B-A)

Nếu Current State Record là một tập hợp rỗng của các danh sách nguồn, thì không có phản hồi nào
được gửi. Sau khi các bản tin Report đã yêu cầu được tạo ra, các danh sách nguồn có liên quan tới
bất kỳ các địa chỉ multicast được báo cáo nào đều được xóa bỏ.

35
TCVN xxxx:2016
4. Nếu bộ đếm thời gian cho việc truyền lại của một địa chỉ multicast kết thúc (tức là có một bản tin
State Change Report đang ở trạng thái chờ cho địa chỉ multicast đó), các nội dung của bản tin
Report được xác định như sau: Nếu bản tin Report chứa Filter Mode Change Record, tức là bộ
đếm truyền lại chế độ lọc cho địa chỉ multicast đó có một giá trị lớn hơn 0, và nếu chế độ lọc
hiện tại của giao diện là INCLUDE, thì bản tin Report sẽ chứa bản ghi TO_IN, ngược lại bản tin
này sẽ chứa bản ghi TO_EX. Trong cả hai trường hợp, bộ đếm truyền lại chế độ lọc cho địa chỉ
multicast đó được giảm một đơn vị sau khi truyền bản tin Report.

Nếu bản tin Report chứa các Source List Change Record, tức là bộ đếm truyền lại chế độ lọc
cho địa chỉ multicast đó bằng 0, thì bản này này sẽ chứa bản ghi ALLOW hoặc BLOCK. Nội
dung của các bản ghi này được xây dựng theo bảng dưới đây:

Bản ghi Các nguồn được bao gồm

---------- ----------------------------------
TO_IN Tất cả các nguồn trong trạng thái từng giao diện hiện tại phải được
chuyển tiếp

TO_EX Tất cả các nguồn trong trạng thái từng giao diện hiện tại phải được
chặn

ALLOW Tất cả các nguồn có trạng thái truyền lại (tức là tất cả các nguồn từ
danh sách truyền lại) phải được chuyển tiếp. Với mỗi nguồn nằm
trong bản tin Report, bộ đếm truyền lại nguồn của nó được giảm 1
đơn vị sau khi truyền bản tin này. Nếu bộ đếm tiến về 0, nguồn được
xóa khỏi danh sách truyền lại cho địa chỉ multicast đó

BLOCK Tất cả các nguồn có trạng thái truyền lại (tức là tất cả các nguồn từ
danh sách truyền lại) phải được chặn. Với mỗi nguồn nằm trong bản
tin này, bộ đếm truyền lại nguồn của nó được giảm 1 đơn vị sau khi
truyền bản tin Report. Nếu bộ đếm tiến về 0, nguồn sẽ bị xóa khỏi
danh sách truyền lại cho địa chỉ multicast đó.

Nếu danh sách nguồn được tính toán cho bản ghi ALLOW hoặc bản ghi BLOCK là rỗng, thì bản
ghi đó sẽ bị loại bỏ khỏi bản tin State Change Report.

10 Mô tả của giao thức cho router multicast

Mục đích của MLD là cho phép router multicast xác định được những địa chỉ multicast nào có đối
tượng nghe trên liên kết được kết nối trực tiếp. So với MLDv1, MLDv2 bổ sung khả năng cho phép
router multicast xác định được những nguồn nào có đối tượng nghe thuộc các nút lân cận, đối với các
gói tin được gửi tới bất kỳ địa chỉ multicast cụ thể nào. Các thông tin thu thập bởi MLD được cung cấp

36
 TCVN xxxx:2016
cho giao thức định tuyến multicast để router sử dụng nhằm đảm bảo các gói tin multicast được phân
phối tới tất cả các liên kết có đối tượng mong muốn nghe.

Phần này mô tả chức năng MLDv2 được thực hiện bởi router multicast. Các router multicast có thể trở
thành các đối tượng nghe địa chỉ multicast, và do đó cũng thực hiện chức năng đối tượng nghe
multicast của MLDv2, như được mô tả trong phần 9.

Một router multicast thực thi giao thức trên mỗi liên kết được kết nối trực tiếp của nó. Nếu một router
multicast có nhiều hơn một giao diện kết nối tới cùng một liên kết, nó chỉ cần thực thi giao thức này qua
một trong số các giao diện đó.

Với mỗi giao diện mà qua đó router thực thi giao thức MLD, router phải cấu hình giao diện đó để nghe
tất cả các địa chỉ multicast tầng liên kết (link-layer) trong IPv6. Ví dụ, router kết nối Ethernet phải thiết
lập bộ lọc tiếp nhận địa chỉ Ethernet của nó chấp nhận tất cả các địa chỉ multicast Ethernet bắt đầu với
giá trị hexa là 3333 [RFC2464]; trong trường hợp giao diện Ethernet không hỗ trợ việc lọc dải địa chỉ
như vậy, thì nó phải được cấu hình để chấp nhận tất cả các địa chỉ multicast Ethernet, nhằm đáp ứng
các yêu cầu của MLD.

Trên mỗi giao diện sử dụng giao thức này, router PHẢI cho phép tiếp nhận địa chỉ multicast tất cả các
router có khả năng hỗ trợ MLDv2 trong phạm vi liên kết từ tất cả các nguồn, và PHẢI thực hiện chức
năng đối tượng nghe địa chỉ multicast của MLDv2 với địa chỉ này trên giao diện đó.

Các router multicast chỉ cần biết trên một liên kết được kết nối có ít nhất một nút đang nghe các gói tin
cho một địa chỉ multicast cụ thể từ một nguồn cụ thể; một router multicast không cần theo dõi một cách
độc lập các quan tâm của từng nút lân cận.

MLDv2 được tương thích ngược với giao thức MLDv1. Chi tiết được mô tả trong phần 11.

10.1 Các điều kiện cho những bản tin Query MLD

Cách xử lý của router thực thi giao thức MLD phụ thuộc vào việc có nhiều router multicast trên cùng
một mạng con hay không. Trong trường hợp đó, cơ chế bầu chọn Querier được sử dụng để lựa chọn
một router multicast duy nhất đóng vai trò là Querier. Tất cả các router multicast trên mạng con lắng
nghe các bản tin được gửi từ các đối tượng nghe multicast và duy trì cùng một trạng thái thông tin
nghe multicast để nếu Querier hiện tại gặp sự cố, các router multicast này có thể đảm nhiệm chức
năng Querier một cách nhanh chóng và chính xác. Tuy nhiên, chỉ có duy nhất một Querier gửi định kỳ
hoặc khởi tạo các bản tin Query trên miền mạng.

Querier định kỳ gửi các bản tin General Query để yêu cầu thông tin của đối tượng nghe địa chỉ
multicast từ một liên kết được kết nối. Các bản tin Query này được sử dụng để thiết lập và làm mới
trạng thái đối tượng nghe địa chỉ multicast của router trên các liên kết được kết nối.

37
TCVN xxxx:2016
Các nút phản hồi lại các bản tin Query này bằng cách thông báo trạng thái nghe địa chỉ multicast của
chúng (và danh sách các nguồn mà chúng đang nghe) qua các Current State Record hiện tại trong bản
tin Report MLDv2.

Với chức năng đối tượng nghe địa chỉ multicast, một nút có thể thể hiện mối quan tâm trong việc có
nghe các lưu lượng đến từ các nguồn nhất định hay không. Khi trạng thái nghe mong muốn của nút
thay đổi, nút sẽ thông báo các thay đổi này bằng cách sử dụng các Filter Mode Change Record hoặc
Source List Change Record. Các bản ghi này chỉ thị một thay đổi trạng thái rõ ràng về địa chỉ multicast
tại một nút trong danh sách nguồn của Multicast Address Record hoặc chế độ lọc của nó. Khi nút kết
thúc việc nghe địa chỉ multicast hoặc không còn nhu cầu nhận lưu lượng từ một nguồn cụ thể, Querier
phải truy vấn các đối tượng nghe khác của địa chỉ multicast hoặc của nguồn trước khi xóa địa chỉ
multicast (hoặc nguồn) khỏi trạng thái đối tượng nghe địa chỉ multicast của nó và ngừng truyền lưu
lượng.

Để cho phép tất cả các nút trên một liên kết phản hồi lại những sự thay đổi trong việc nghe địa chỉ
multicast, Querier sẽ gửi đi các bản tin Query cụ thể. Một bản tin Multicast Address Specific Query
được gửi để xác minh rằng không có nút nào đang nghe 1 địa chỉ multicast xác định hoặc để thiết lập
lại trạng thái nghe cho 1 địa chỉ multicast xác định. Các bản tin Multicast Address Specific Query được
gửi khi Querier nhận được State Change Record chỉ thị rằng một nút ngừng theo dõi một địa chỉ
multicast. Chúng cũng được gửi để cho phép router chuyển nhanh từ chế độ EXCLUDE sang chế độ
INCLUDE, trong trường hợp nhận được một State Change Record yêu cầu việc chuyển đổi này.

Bản tin Multicast Address and Source Specific Query được sử dụng để xác minh rằng không có nút
nào trên liên kết đang nghe lưu lượng từ một tập hợp nguồn cụ thể. Các bản tin Multicast Address and
Source Specific Query liệt kê các nguồn cho một địa chỉ multicast cụ thể không còn nhu cầu được
chuyển tiếp nữa. Bản tin Query này được Querier gửi đi, để xác định có hay không một (các) nút đang
nghe các gói tin được gửi đến địa chỉ multicast cụ thể từ các địa chỉ nguồn cụ thể. Các bản tin Multicast
Address and Source Specific Query chỉ được gửi để phản hồi lại các State Change Record mà không
bao giờ phản hồi lại các Current State Record.

10.2 Trạng thái MLD được duy trì bởi các router multicast

Các router multicast thực thi giao thức MLDv2 lưu trạng thái cho từng địa chi multicast đối với từng liên
kết được kết nối. Trạng thái địa chỉ multicast này bao gồm 1 chế độ lọc, một danh sách các nguồn và
các bộ đếm thời gian khác nhau. Đối với từng liên kết được kết nối mà MLD đang thực hiện, router
multicast ghi lại trạng thái nghe cho từng liên kết đó. Trạng thái đó bao gồm một tập hợp các bản ghi
theo dạng sau:

(Địa chỉ multicast IPv6, chế độ lọc, Chế độ lọc của router, (các bản ghi nguồn))

Mỗi một bản ghi nguồn được biểu diễn theo dạng:

38
 TCVN xxxx:2016
(Địa chỉ nguồn IPv6, bộ đếm thời gian của nguồn)

Nếu tất cả các nguồn cho một địa chỉ multicast đang được lắng nghe, thì chế độ lọc của router được
thiết lập sang EXCLUDE với danh sách bản ghi nguồn không chứa địa chỉ nguồn nào. Điều này có
nghĩa rằng tất cả các nguồn cho địa chỉ multicast này đều được chuyển tiếp. Trường hợp này của
MLDv2 tương đương với trạng thái nghe của MLDv1.

10.2.1 Định nghĩa các chế độ lọc của router

Để giảm trạng thái cục bộ, các router MLDv2 duy trì một chế độ lọc đối với từng địa chỉ multicast trên
từng liên kết được kết nối. Chế độ lọc này được sử dụng để tổng hợp tất cả các trạng thái nghe địa chỉ
multicast thành một tập hợp nhỏ nhất chứa trạng thái nghe của tất cả các nút. Chế độ lọc có thể thay
đổi tương ứng với việc nhận các loại Multicast Address Record cụ thể hoặc khi các điều kiện cho một
bộ đếm thời gian nào đó xảy ra. Trong các phần tiếp theo, thuật ngữ “chế độ lọc của router” được sử
dụng để đề cập đến chế độ lọc của một địa chỉ multicast cụ thể trong router. Phần 10.4 mô tả những
thay đổi về chế độ lọc của router cho từng Multicast Address Record nhận được.

Một router ở chế độ INCLUDE cho một địa chỉ multicast cụ thể trên 1 giao diện xác định nếu tất cả các
đối tượng nghe trên liên kết đang theo dõi địa chỉ đó ở chế độ INCLUDE. Trạng thái router được biểu
diễn bằng INCLUDE (A), trong đó A được gọi là “danh sách INCLUDE”. Danh sách INCLUDE là một
tập hợp các nguồn mà ít nhất một đối tượng nghe trên liên kết có yêu cầu muốn nhận gói tin. Tất cả
các nguồn trong danh sách INCLUDE sẽ được chuyển tiếp bởi router. Bất kỳ nguồn nào không nằm
trong danh sách INCLUDE sẽ bị router chặn lại.

Một router sẽ có chế độ lọc là EXCLUDE cho một địa chỉ multicast cụ thể trên một giao diện xác định
nếu có ít nhất một đối tượng nghe trong chế độ EXCLUDE đang có nhu cầu nghe địa chỉ này trên liên
kết. Khi nhận được một Multicast Address Record, chế độ lọc của router cho địa chỉ multicast đó được
cập nhật để kiểm soát tất cả các nguồn được yêu cầu sử dụng ít trạng thái nhất. Theo quy tắc, khi
nhận được Multicast Address Record có chế độ lọc EXCLUDE thì chế độ lọc của router cho địa chỉ
multicast đó sẽ được thiết lập thành EXCLUDE. Tuy nhiên, nếu tất cả các nút với Multicast Address
Record có chế độ lọc được thiết lập là EXCLUDE dừng báo cáo, thì chế độ lọc của router cho địa chỉ
multicast đó sẽ được chuyển ngược lại chế độ INCLUDE. Việc chuyển trạng thái này xảy ra khi bộ đếm
thời gian chế độ lọc kết thúc, và được giải thích cụ thể trong phần 10.5.

Khi router ở trong chế độ EXCLUDE, trạng thái router được biểu diễn bằng EXCLUDE (X,Y), trong đó
X là ”danh sách được yêu cầu” và Y là “danh sách EXCLUDE”. Tất cả các nguồn nằm ngoài danh sách
EXCLUDE sẽ được chuyển tiếp bởi router. Danh sách được yêu cầu không ảnh hưởng đến việc
chuyển tiếp này. Tuy nhiên, nó vẫn được duy trì vì một số lý do, được giải thích trong phần 10.2.3.

Việc xử lý chính xác trạng thái router ở cả chế độ INCLUDE và EXCLUDE, theo các bản tin Report
nhận được được thể hiện chi tiết trong các bảng phần 10.4.1 và 10.4.2.

39
 TCVN xxxx:2016
10.2.2 Định nghĩa các bộ đếm thời gian cho chế độ lọc

Bộ đếm thời gian cho chế độ lọc chỉ được sử dụng khi router ở chế độ EXCLUDE cho một địa chỉ
multicast cụ thể, và nó thể hiện khoảng thời gian cho chế độ lọc EXCLUDE của router đối với địa chỉ
multicast đó, sau khi hết thời gian này router sẽ chuyển sang chế độ INCLUDE. Bộ đếm thời gian cho
chế độ lọc là một bộ đếm thời gian đếm giảm dần về ngưỡng nhỏ hơn 0. Bộ đếm thời gian cho chế độ
lọc tồn tại cho từng Multicast Address Record. Các bộ đếm thời gian cho chế độ lọc được cập nhật
theo các loại Multicast Address Record nhận được.

Nếu một bộ đếm thời gian cho chế độ lọc kết thúc mà chế độ lọc của router cho một địa chỉ multicast là
EXCLUDE, thì không còn đối tượng nghe nào ở chế độ EXCLUDE trên liên kết được kết nối. Tại thời
điểm này, router chuyển sang chế độ lọc INCLUDE. Phần 10.5 mô tả các hoạt động xảy ra khi bộ đếm
thời gian cho chế độ lọc của chế độ EXCLUDE kết thúc.

Bảng sau tổng hợp ý nghĩa của bộ đếm thời gian. Phần 10.4 mô tả chi tiết về việc thiết lập bộ đếm thời
gian cho chế độ lọc đối với từng loại Multicast Address Record nhận được.

Chế độ lọc của router Giá trị bộ đếm thời gian Các hoạt động / khuyến nghị
cho chế độ lọc
----------------------------- ----------------------------------- ---------------------------------------
INCLUDE Không được sử dụng Tất cả các đối tượng nghe ở chế độ INCLUDE
EXCLUDE Bộ đếm thời gian > 0 Ít nhất một đối tượng nghe ở chế độ EXCLUDE
EXCLUDE Bộ đếm thời gian = 0 Không còn đối tượng nghe nào ở chế độ
EXCLUDE cho một địa chỉ multicast. Nếu danh
sách được yêu cầu là rỗng thì xóa Multicast
Address Record. Nếu không, chuyển sang chế độ
lọc INCLUDE, các nguồn trong danh sách được
yêu cầu được chuyển sang danh sách INCLUDE,
và danh sách EXCLUDE sẽ bị xóa bỏ.

10.2.3 Định nghĩa các bộ đếm thời gian cho nguồn

Bộ đếm thời gian cho nguồn là một bộ đếm thời gian đếm giảm dần về ngưỡng nhỏ hơn 0. Mỗi bản ghi
nguồn có một bộ đếm thời gian cho nguồn đó. Các bộ đếm thời gian cho nguồn được cập nhật theo
loại và chế độ lọc của Multicast Address Record nhận được. Phần 10.4 mô tả việc thiết lập bộ đếm thời
gian cho nguồn đối với từng loại Multicast Address Record nhận được.

Trong các phần sau của tiêu chuẩn này, các quy ước về chữ viết tắt như sau được sử dụng. Biến
MALI viết tắt của khoảng thời gian nghe địa chỉ multicast (Multicast Address Listening Interval), là
khoảng thời gian mà trạng thái nghe địa chỉ multicast sẽ kết thúc. Biến LLQT viết tắt của thời gian truy
vấn đối tượng nghe cuối cùng (Last Listener Query Time), là thời gian tổng cộng mà router đợi bản tin

40
 TCVN xxxx:2016
Report, sau khi Querier gửi đi bản tin Query đầu tiên. Trong suốt khoảng thời gian này, router sẽ truyền
lại [LLQC] -1 bản tin Query. LLQT thể hiện “trễ rời nhóm”, hoặc sai lệch thời gian giữa việc truyền thay
đổi trạng thái đối tượng nghe và việc thay đổi thông tin khi truyền qua giao thức định tuyến.

Nếu router có chế độ lọc INCLUDE thì một nguồn có thể sẽ được bổ sung vào danh sách INCLUDE
hiện tại nếu có một đối tượng nghe ở chế độ INCLUDE gửi đi bản tin Current State Report hoặc bản tin
State Change Report chứa nguồn này. Mỗi nguồn từ danh sách INCLUDE được liên kết với một bộ
đếm thời gian cho nguồn – được cập nhật bất cứ khi nào một đối tượng nghe trong chế độ INCLUDE
gửi đi một bản tin Report để xác nhận mối quan tâm của đối tượng nghe này tới một địa chỉ nguồn cụ
thể. Nếu bộ đếm thời gian cho nguồn từ danh sách INCLUDE kết thúc, nguồn sẽ bị xóa khởi danh sách
INCLUDE. Nếu không còn bản ghi nguồn nào nữa, Multicast Address Record sẽ bị xóa khỏi router.

Bên cạnh phương thức “rời nhóm mềm” này, còn 1 phương thức “rời nhóm nhanh” của MLDv2; được
dựa trên việc sử dụng bộ đếm thời gian cho nguồn. Khi một nút ở trong chế độ INCLUDE muốn ngừng
nghe một nguồn cụ thể, tất cả các router multicast trên liên kết phải hạ thấp bộ đếm thời gian của mình
cho nguồn đó xuống thành một khoảng thời gian nhỏ bằng LLQT mili-giây. Querier sau đó gửi đi một
bản tin Multicast Address and Source Specific Query, để xác minh rằng có đối tượng nghe nào khác
cho nguồn đó còn trên liên kết nữa hay không. Nếu nhận được bản tin Report tương ứng trước khi bộ
đếm thời gian kết thúc, tất cả các router multicast trên liên kết sẽ cập nhật bộ đếm thời gian cho nguồn
của mình. Nếu không, nguồn sẽ bị xóa khỏi danh sách INCLUDE. Việc xử lý danh sách INCLUDE theo
bản tin Report nhận được được cụ thể trong bảng phần 10.4.1 và 10.4.2.

Bộ đếm thời gian cho nguồn được xử lý độc lập khi chế độ lọc của router cho địa chỉ multicast là chế
độ EXCLUDE. Với các nguồn trong danh sách được yêu cầu có bộ đếm thời gian nguồn đang chạy thì
các nguồn này được chuyển tiếp bởi router. Với các nguồn trong danh sách EXCLUDE có bộ đếm thời
gian cho nguồn được thiết lập bằng 0 thì những nguồn này sẽ bị router chặn lại. Nếu bộ đếm thời gian
của một nguồn trong danh sách được yêu cầu kết thúc thì nguồn này sẽ được chuyển sang danh sách
EXCLUDE. Sau đó router thông báo cho các giao thức định tuyến rằng không còn đối tượng nghe nào
trên liên kết có nhu cầu nhận lưu lượng từ nguồn này nữa.

Router phải duy trì danh sách được yêu cầu vì 2 lý do sau:

 Để theo dõi các nguồn mà đối tượng nghe có chế độ lọc INCLUDE đang lắng nghe. Điều này
nhằm đảm bảo việc chuyển đổi liền mạch của router sang chế độ INCLUDE, khi không còn đối
tượng nghe nào ở chế độ EXCLUDE nữa. Việc chuyển đổi này sẽ không làm gián đoạn lưu
lượng tới những đối tượng nghe ở chế độ INCLUDE vẫn đang theo dõi địa chỉ multicast đó. Do
đó, tại thời điểm chuyển đổi, danh sách được yêu cầu sẽ chứa tập hợp các nguồn mà các nút
có chế độ lọc INCLUDE đã yêu cầu một cách rõ ràng.

Khi router chuyển sang chế độ INCLUDE, các nguồn trong danh sách được yêu cầu sẽ chuyển
sang danh sách INCLUDE, và danh sách EXCLUDE sẽ bị xóa bỏ. Trước khi chuyển, danh sách

41
TCVN xxxx:2016
được yêu cầu có thể chứa những dự đoán không chính xác về các nguồn mà những đối tượng
nghe trong chế độ INCLUDE đang nghe – có thể quá lớn hoặc quá nhỏ. Những dự đoán không
chính xác này dựa theo thực tế rằng danh sách được yêu cầu cũng được sử dụng cho mục
đích ngăn chặn nhanh chóng, như được mô tả dưới đây. Nếu tồn tại một yêu cầu chặn nhanh
như vậy, nhiều nguồn có thể bị xóa khỏi danh sách được yêu cầu (như được chỉ ra trong phần
10.4.1 và 10.4.2) nhằm hạn chế trạng thái router. Tuy nhiên, trong mỗi trường hợp như vậy, bộ
đếm thời gian cho chế độ lọc cũng được cập nhật. Do đó,trước khi thực hiện chuyển đổi, các
đối tượng nghe trong chế độ INCLUDE sẽ có đủ thời gian để xác minh lại mối quan tâm của các
đối tượng này với các nguồn bị loại trừ, và thiết lập lại danh sách được yêu cầu phụ hợp. Giao
thức đảm bảo rằng khi xảy ra chuyển đổi sang chế độ INCLUDE, danh sách được yêu cầu là
chính xác.

 Để cho phép việc chặn nhanh các nguồn không được chặn trước đó. Nếu router nhận được
bản tin Report chứa một yêu cầu như vậy, các nguồn có liên quan phải được thêm vào danh
sách được yêu cầu. Các bộ đếm thời gian của chúng được thiết lập về một giá trị nhỏ bằng
LLQT mili-giây, và một bản tin Multicast Address and Source Specific Query được gửi bởi
Querier, để kiểm tra rằng còn nút còn trên liên kết vẫn còn mong muốn nghe các nguồn này
nữa không. Nếu không nút nào xác nhận mối quan tâm của nó tới việc nhận lưu lượng từ
nguồn cụ thể này nữa, thì bộ đếm thời gian cho nguồn này sẽ kết thúc. Sau đó, nguồn này sẽ
được chuyển từ danh sách được yêu cầu sang danh sách EXCLUDE. Từ thời điểm đó, nguồn
sẽ bị router chặn lại.

Việc xử lý của trạng thái router có chế độ EXCLUDE, theo các bản tin Report nhận được, được cụ thể
hóa trong phần 10.4.1 và 10.4.2.

Khi chế độ lọc của router cho địa chỉ multicast là EXCLUDE, bản ghi nguồn chỉ được xóa khi bộ đếm
thời gian cho chế độ lọc kết thúc, hoặc khi một bản ghi địa chỉ nguồn mới nhận được làm thay đổi danh
sách bản ghi nguồn của router

10.3 Các quy tắc chuyển tiếp nguồn MLDv2 cụ thể

Khi một router multicast nhận được một gói dữ liệu từ một nguồn nào đó có đích là một địa chỉ
multicast cụ thể, router phải quyết định có chuyển tiếp gói dữ liệu này sang liên kết được kết nối hay
không. Giao thức định tuyến multicast được sử dụng để điều phối quyết định này, và sẽ sử dụng các
thông tin MLDv2 để đảm bảo rằng tất cả các nguồn/ các địa chỉ multicast mà có đối tượng nghe trên
một liên kết đều được chuyển tiếp sang liên kết đó. Các thông tin MLDv2 không phủ định các thông tin
định tuyến multicast, ví dụ, nếu chế độ lọc MLDv2 cho một địa chỉ multicast là EXCLUDE, router có thể
vẫn chuyển tiếp các gói tin có nguồn được loại trừ này sang liên kết.

Bảng sau mô tả các khuyến nghị chuyển tiếp được tạo bởi MLDv2 tới giao thức định tuyến cho các lưu
lượng được khởi tạo từ một nguồn có đích là một địa chỉ multicast. Đây cũng là tổng hợp các hành

42
 TCVN xxxx:2016
động diễn ra khi kết thúc bộ đếm thời gian nguồn dựa trên chế độ lọc của router của một địa chỉ
multicast.

Chế độ lọc của router Giá trị bộ đếm thời gian Hành động / khuyến nghị
cho nguồn
----------------------------- ------------------------------- -----------------------------------

INCLUDE Bộ đếm thời gian > 0 Đề nghị chuyển tiếp lưu tượng từ nguồn

INCLUDE Bộ đếm thời gian == 0 Đề nghị dừng chuyển tiếp lưu lượng từ nguồn và
xóa bỏ bản ghi nguồn. Nếu không có bản ghi
nguồn nào, thì xóa Multicast Address Record

EXCLUDE Bộ đếm thời gian > 0 Đề nghị chuyển tiếp lưu lượng từ nguồn

EXCLUDE Bộ đếm thời gian == 0 Đề nghị không chuyển tiếp lưu lượng từ nguồn.
Chuyển nguồn từ danh sách được yêu cầu sang
danh sách EXCLUDE (không xóa bản ghi nguồn)

EXCLUDE Không có nguồn nào Đề nghị chuyển tiếp lưu lượng từ tất cả các nguồn

10.4 Xử lý khi nhận bản tin Report

Khi nhận được bản tin Report MLD, router sẽ kiểm tra: địa chỉ nguồn của bản tin có phải địa chỉ link-
local hợp lệ, trường Hop Limit có được thiết lập bằng 1, và tùy chọn Router Alert có xuất hiện trong
mào đầu Hop-by-Hop Options của gói tin IPv6 hay không. Nếu bất kỳ kiểm tra nào bị lỗi, thì gói tin sẽ bị
bỏ qua. Nếu tính hợp lệ của bản tin MLD được xác minh, router sẽ bắt đầu xử lý bản tin Report.

10.4.1 Khi nhận các Current State Record

Khi nhận được các Current State Record, router cập nhật cả bộ đếm thời gian cho chế độ lọc và bộ
đếm thời gian cho nguồn của nó. Trong một số trường hợp, việc nhận được một loại Multicast Address
Record sẽ làm thay đổi chế độ lọc của router cho một địa chỉ multicast. Bảng dưới đây mô tả các hành
động xảy ra với trạng thái của router khi nhận được Current State Record, bao gồm cả trạng thái và
các bộ đếm thời gian.

Nếu router ở trong chế độ lọc INCLUDE cho một địa chỉ multicast, ký hiệu INCLUDE (A) sẽ được sử
dụng, trong đó A biểu hiện danh sách INCLUDE có liên quan. Nếu router ở trong chế độ EXCLUDE
cho một địa chỉ multicast cụ thể thì sử dụng ký hiệu EXCLUDE (X,Y), trong đó X thể hiện danh sách
được yêu cầu và Y thể hiện danh sách EXCLUDE có liên quan.

Trong phần “hành động” của bảng trạng thái router, thì ký hiệu ‘(A)=J’ có nghĩa là tập hợp A của các
bản ghi nguồn sẽ có bộ đếm thời gian cho nguồn được thiết lập bằng giá trị J. “Xóa A” có nghĩa rằng
tập hợp A các bản ghi nguồn sẽ được xóa. “Bộ đếm thời gian cho chế độ lọc = J” có nghĩa rằng giá trị
của bộ đếm thời gian cho chế độ lọc đối với địa chỉ multicast sẽ được thiết lập bằng giá trị J.
43
TCVN xxxx:2016
Trạng thái router Bản tin Report nhận được Trạng thái router mới Hành động
----------------------- ----------------------------------- ----------------------------- ---------------
INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B)=MALI

INCLUDE (A) IS_EX (B) EXCLUDE (A*B, B-A) (B-A)=0

Xóa (A-B)

Bộ đếm thời gian cho chế độ

lọc = MALI

EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+A, Y-A) (A) = MALI

EXCLUDE (X,Y) IS_EX (A) EXCLUDE (A-Y,Y*A) (A – X – Y) = MALI

Xóa (X-A)

Xóa (Y-A)

Bộ đếm thời gian cho chế độ

lọc = MALI

10.4.2 Khi nhận các Filter Mode Change Record và Source List Change Record
Khi có một thay đổi trong trạng thái toàn cục của địa chỉ multicast xảy ra tại 1 nút, nút này sẽ gửi đi
Source List Change Record hoặc là Filter Mode Change Record cho địa chỉ multicast đó. Đối với các
Current State Record, các router phải xử lý được các bản ghi này và thay đổi trạng thái của chính
chúng để phản hồi lại trạng thái nghe mới của liên kết.

Các Querier phải truy vấn các nguồn hoặc các địa chỉ multicast mà không còn được yêu cầu chuyển
tiếp nữa. Khi router gửi hoặc nhận một bản tin Query cho một tập hợp cụ thể các nguồn, nó giảm bộ
đếm thời gian nguồn của mình cho các địa chỉ đó tới một giá trị thời gian bằng LLQT theo đơn vị mili-
giây. Nếu các Multicast Address Record nhận được để phản hồi lại các bản tin Query cho việc nghe
các nguồn được truy vấn, thì các bộ đếm thời gian tương ứng sẽ được cập nhật.

Các bản tin Multicast Address Specific Query cũng có thể được sử dụng để cho phép router chuyển đổi
nhanh chóng từ chế độ EXCLUDE sang chế độ INCLUDE, trong trường hợp nhận được một Multicast
Address Record yêu cầu việc chuyển đổi này. Bộ đếm thời gian cho chế độ lọc đối với địa chỉ multicast
đó được làm giảm đến một giá trị bằng LLQT theo mili-giây. Nếu nhận được bất kỳ Multicast Address
Record nào có chế độ EXCLUDE mong muốn nghe địa chỉ multicast trên trong khoảng thời gian này,
thì bộ đếm thời gian cho chế độ lọc sẽ được cập nhật và yêu cầu giao thức định tuyến chuyển tiếp địa
chỉ multicast mà không gặp bất kỳ gián đoạn nào. Nếu không, router sẽ chuyển sang chế độ INCLUDE
cho địa chỉ multicast đó.

Trong suốt LLQT (theo mili-giây), router MLD tiếp tục yêu cầu giao thức định tuyến chuyển tiếp lưu
lượng từ những địa chỉ multicast hoặc những nguồn được truy vấn. Router sẽ không thực hiện việc

44
 TCVN xxxx:2016
này nếu sau LLQT theo milli-giây mà không nhận được một bản ghi nào thể hiện mối quan tâm đến địa
chỉ hoặc các nguồn được truy vấn, sau đó router có thể loại bỏ địa chỉ multicast hoặc các nguồn này
khỏi liên kết.

Bảng dưới đây mô tả các thay đổi trong trạng thái địa chỉ multicast và các hành động xảy ra khi nhận
được các Filter Mode Change hoặc Source List Change Record. Bảng này cũng mô tả các bản tin
Query được gửi bởi Querier khi một bản tin Report cụ thể nhận được.

Các bản tin Query gửi đi được biểu diễn bằng các ký hiệu. Ký hiệu ‘Q(MA)’ để mô tả việc gửi bản tin
Multicast Address Specific Query tới một địa chỉ multicast MA. Ký hiệu ‘Q(MA,A)’ để mô tả việc gửi bản
tin Multicast Address and Source Specific Query tới địa chỉ multicast MA với danh sách nguồn A. Nếu
danh sách nguồn A không chứa nguồn nào vì một hành động nào đó (ví dụ A*B) thì không có bản tin
Query nào được gửi.

Để duy trì tính ổn định của giao thức, các bản tin Query được định nghĩa trong cột hành động của bảng
sau cần được truyền trong [LLQC] lần mỗi bản tin được gửi đi sau mỗi khoảng thời gian bằng [LLQI].

Nếu trong khi lập lịch cho các bản tin Query mới, tồn tại các bản tin Query đang ở chế độ chờ được gửi
cho cùng 1 địa chỉ multicast, thì các bản tin Query mới và các bản tin Query đang được chờ sẽ được
gộp lại. Ngoài ra, các bản tin Report của host nhận được cho một địa chỉ multicast có các bản tin Query
đang ở trạng thái chờ có thể ảnh hưởng tới nội dung của các bản tin Query đó. Phần 10.6.3 mô tả tiến
trình xây dựng và duy trì trạng thái của các bản tin Query đang chờ.

Trạng thái router Bản tin Report nhận được Trạng thái router Hành động
---------------------- ----------------------------------- mới ---------------
----------------------------
INCLUDE (A) CHO PHÉP (B) INCLUDE (A+B) (B)= MALI
INCLUDE (A) CHẶN (B) INCLUDE (A) Gửi đi Q(MA,A*B)
INCLUDE (A) TO_EX (B) EXCLUDE (A*B,B- (B-A) = 0
A) Xóa (A-B)
Gửi đi Q(MA,A*B)
Bộ đếm thời gian cho chế độ
lọc = MALI
INCLUDE (A) TO_IN INCLUDE (A+B) (B) = MALI
Gửi đi Q (MA,A-B)
EXCLUDE (X,Y) CHO PHÉP (A) EXCLUDE(X+A,Y-A) (A)= MALI
EXCLUDE (X,Y) CHẶN (A) EXCLUDE (X+(A-Y), (A-X-Y) = bộ đếm thời gian
Y) cho chế độ lọc
Gửi đi Q(MA,A-Y)
EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A- (A-X-Y) = bộ đếm thời gian
Y,Y*A) cho chế độ lọc
Xóa (X-A)

45
TCVN xxxx:2016
Xóa (Y-A)
Gửi đi Q(MA,A-Y)
Bộ đếm thời gian cho chế độ
lọc = MALI
EXCLUDE (X,Y) TO_IN (A) EXCLUDE (X+A,Y- (A)=MALI
A) Gửi đi Q(MA,X-A)
Gửi đi Q(MA)

10.5 Chuyển đổi các chế độ lọc của router

Bộ đếm thời gian cho chế độ lọc được sử dụng như một cơ chế cho việc chuyển đổi chế độ lọc của
router từ EXCLUDE sang INCLUDE

Khi bộ đếm thời gian cho chế độ lọc EXCLUDE của router kết thúc, router giả định rằng không có nút
nào có chế độ lọc EXCLUDE hiện diện trong liên kết được kết nối. Do đó, router chuyển sang chế độ
lọc INCLUDE với địa chỉ multicast.

Một router sử dụng các nguồn trong danh sách được yêu cầu làm trạng thái của nó cho việc chuyển
sang chế độ lọc INCLUDE. Các nguồn trong danh sách được yêu cầu được chuyển sang danh sách
INCLUDE, trong khi các nguồn trong danh sách EXCLUDE bị xóa bỏ. Ví dụ, nếu trạng thái của router
cho một địa chỉ multicast là EXCLUDE(X,Y) và bộ đếm thời gian cho chế độ lọc đối với địa chỉ multicast
đó kết thúc, router sẽ chuyển sang chế độ lọc INCLUDE với trạng thái INCLUDE(X). Nếu tại thời điểm
chuyển đổi danh sách được yêu cầu (X) là rỗng, Multicast Address Record sẽ bị xóa khỏi router.

10.6 Các xử lý khi nhận bản tin Query

Khi nhận được một bản tin Query, router kiểm tra địa chỉ nguồn của bản tin có phải là một địa chỉ link-
local hợp lệ, trường Hop Limit có được thiết lập bằng 1, và tùy chọn Router Alert có xuất hiện trong
mào đầu Hop-by-Hop Options của gói tin IPv6 hay không. Nếu bất kỳ kiểm tra nào có lỗi, gói tin sẽ
được loại bỏ. Nếu tính hợp lệ được xác minh, router sẽ bắt đầu xử lý bản tin Query.

10.6.1 Cập nhật bộ đếm thời gian

MLDv2 sử dụng cờ S (chặn xử lý phía router) để đảm bảo tính ổn định như được giải thích trong phần
5.1. Khi một router gửi đi hoặc nhận một bản tin Query có cờ S rõ ràng, nó phải cập nhật bộ đếm thời
gian của mình để phản hồi lại giá trị kết thúc chính xác cho địa chỉ multicast và nguồn đang được truy
vấn. Bảng tiếp theo mô tả các xử lý của bộ đếm thời gian khi gửi và nhận một bản tin Multicast Address
Specific Query hoặc bản tin Multicast Address and Source Specific Query với cờ S không được thiết
lập.

46
 TCVN xxxx:2016
Truy vấn Xử lý
----------- --------

Q(MA,A) Bộ đếm thời gian nguồn cho các nguồn trong A được hạ thấp về LLQT

Q(MA) Bộ đếm thời gian cho chế độ lọc được hạ về LLQT

Khi một router gửi và nhận một bản tin Query vời cờ S được thiết lập, nó sẽ không cập nhật bộ đếm
thời gian của mình.

10.6.2 Bầu chọn Querier

MLDv2 lựa chọn một router duy nhất cho từng mạng con trong trạng thái Querier; tất cả các router
khác trong mạng con sẽ ở trạng thái non-Querier. MLDv2 sử dụng cơ chế bầu chọn Querier dựa trên
địa chỉ IPv6 giống như MLDv1. Khi một router bắt đầu hoạt động trong một miền mạng, theo mặc định
nó sẽ xem mình như một Querier. Do đó, nó sẽ gửi đi nhiều bản tin General Query cách nhau một
khoảng thời gian nhỏ (xem phần 12.6 và 12.7)

Khi một router nhận một bản tin Query có địa chỉ IPv6 thấp hơn địa chỉ IPv6 của nó, nó thiết lập bộ đếm
thời gian hiển thị Querier khác thành một giá trị được gọi là thời gian kết thúc hiển thị Querier khác; nếu
trước đó router ở trạng thái Querier, nó sẽ chuyển sang trạng thái non-Querier và ngừng gửi các bản
tin Query trên liên kết này. Sau khi bộ đếm thời gian hiển thị Querier khác kết thúc, nó sẽ trở lại trạng
thái Querier và bắt đầu gửi đi các bản tin General Query.

Tất cả các bản tin Query MLDv2 PHẢI được gửi với tiền tố địa chỉ nguồn link-local FE80::/64. Do đó,
với mục đích bầu chọn Querier MLDv2, địa chỉ IPv6 A được xem như là thấp hơn địa chỉ IPv6 B nếu ID
giao diện địa chỉ A (tượng trưng bởi 64 bít cuối của địa chỉ A) là thấp hơn ID giao địa chỉ B (64 bit cuối
của địa chỉ B).

10.6.3 Thiết lập và gửi đi các bản tin Query cụ thể

10.6.3.1 Thiết lập và gửi đi các bản tin Multicast Address Specific Query
Khi xuất hiện một hành đồng “gửi Q(MA)”, bộ đếm thời gian cho chế độ lọc của router phải được hạ
thấp về giá trị LLQT. Querier ngay sau đó sẽ gửi đi một bản tin Multicast Address Specific Query và lập
lịch truyền lại [LLQC -1] bản tin Query, mỗi bản tin được gửi đi sau mỗi khoảng thời gian bằng [LLQI],
trong thời gian [LLQT].

Khi phát đi một bản tin Multicast Address Specific Query, nếu giá trị của bộ đếm thời gian cho chế độ
lọc lớn hơn LLQT, thì cờ S được thiết lập trong bản bản tin Query

10.6.3.2 Thiết lập và gừi đi các bản tin Multicast Address and Source Specific Query
Khi một Querier phát hiện hành động “gửi Q(MA,X)” như trong bảng phần 10.4.2, các xử lý sau đây
phải được thực hiện đối với mỗi nguồn trong X gửi đi địa chỉ multicast MA, có bộ đếm thời gian cho
nguồn lớn hơn LLQT:

 Giảm thời gian bộ đếm thời gian cho nguồn bằng LLQT;

47
TCVN xxxx:2016
 Thêm các nguồn vào danh sách truyền lại;

 Thiết lập bộ đếm cho việc truyền lại nguồn đối với từng nguồn bằng [LLQC]

Querier sau đó phải ngay lập tức gửi đi bản tin Multicast Address and Source Specific Query cũng như
lập lịch truyền lại [LLQC -1] bản tin Query, mỗi bản tin được gửi đi sau mỗi khoảng thời gian bằng
[LLQI], trong thời gian [LLQT]. Nội dung của các bản tin Query này được tính toán như sau:

Khi thiết lập bản tin Multicast Address and Source Specific Query cho địa chỉ multicast MA, hai bản tin
Query riêng biệt được gửi đi cho địa chỉ multicast này. Bản tin Query đầu tiên có bit S được thiết lập và
chứa tất cả các nguồn có trạng thái truyền lại (tức là các nguồn từ danh sách truyền lại của địa chỉ
multicast), và bộ đếm thời gian lớn hơn LLQT. Bản tin Query thứ 2 có bit S không được thiết lập và
chứa các địa chỉ nguồn có trạng thái truyền lại và bộ đếm thời gian nhỏ hơn hoặc bằng LLQT. Nếu một
trong hai bản tin được tính toán không chứa bất kỳ nguồn nào, thì router sẽ ngừng truyền bản tin đó.

Chú ý rằng: Nếu một bản tin Multicast Address Specific Query được lập lịch để truyền cùng thời điểm
với bản tin Multicast Address and Source Specific Query cho cùng địa chỉ multicast, thì việc truyền bản
tin Multicast Address and Source Specific Query với bit S được thiết lập có thể bị chặn lại.

11 Tính tương thích với MLDv1

Các host và router MLDv2 tương thích với các host và router chưa được nâng cấp lên MLDv2. Tính
tương thích này được duy trì do các host và router thực hiện các xử lý thích hợp phụ thuộc vào phiên
bản của MLD đang hoạt động trên các host và router trong mạng.

11.1 Sự khác biệt về phiên bản của bản tin Query

Phiên bản MLD của bản tin Query được xác định như sau:
Bản tin Query MLDv1: độ dài = 24 octet
Bản tin Query MLDv2: độ dài >= 28 octet
Bản tin Query không phù hợp với các điều kiện ở trên (ví dụ bản tin Query có độ dài 26 octet) PHẢI
được tự động bỏ qua.

11.2 Cách xử lý của đối tượng nghe địa chỉ multicast

11.2.1 Trường hợp có sự hiện diện của router MLDv1

Để tương thích với các router MLDv1, các host MLDv2 PHẢI hoạt động trong chế độ tương thích với
phiên bản 1. Các host MLDv2 PHẢI giữ trạng thái cho từng giao diện cục bộ trên góc độ quan tâm đến
chế độ tương thích của mỗi liên kết được kết nối. Tính tương thích của host được xác định từ biến chế
độ tương thích host (Host Compatibility Mode) mà có thể là một trong hai giá trị sau: MLDv1 hoặc
MLDv2.

Chế độ tương thích host của một giao diện được thiết lập là MLDv1 bất cứ khi nào một bản tin Query
MLDv1 nhận được trên giao diện đó. Tại cùng thời điểm, bộ đếm thời gian thể hiện Querier phiên bản
cũ cho giao diện được đặt bằng giá trị [thời gian chờ cho Querier phiên bản cũ hơn] giây. Bộ đếm thời

48
 TCVN xxxx:2016
gian được thiết lập lại bất cứ khi nào một bản tin Query MLDv1 được nhận trên giao diện đó. Nếu bộ
đếm thời gian thể hiện Querier phiên bản cũ hơn kết thúc, host sẽ chuyển được sang chế độ tương
thích host là MLDv2.

Khi chế độ tương thích host là MLDv2, host hoạt động bằng cách sử dụng giao thức MLDv2 trên giao
diện được thiết lập. Khi chế độ tương thích host là MLDv1, host sử dụng duy nhất giao thức MLDv1
trên giao diện đó.

Querier MLDv1 sẽ gửi bản bản tin General Query có trường Maximum Response Code được đặt bằng
trễ phản hồi tối đa mong muốn, tức là dải đầy đủ của trường này là thuật toán lũy thừa và tuyến tính
như được mô tả trong mục 8.1.3 sẽ không được sử dụng.

Bất cứ khi nào host thay đổi chế độ tương thích của nó, nó sẽ hủy bỏ tất cả các các bộ đếm thời gian
truyền lại và các phản hồi đang trong trạng thái chờ của mình.

11.2.2. Trường hợp có sự hiện diện của các đối tượng nghe địa chỉ multicast MLDv1
Một host MLDv2 có thể được đặt trên một liên kết có các host MLDv1. Host này CÓ THỂ cho phép bản
tin Report MLDv2 của nó được chặn bởi một bản tin Report phiên bản 1.

11.3 Cách xử lý của router multicast

11.3.1. Trường hợp có sự hiện diện của router MLDv1

Router MLDv2 có thể được đặt trong mạng mà ở đó có ít nhất một router MLDv1. Các yêu cầu sau
phải được áp dụng:

 Nếu một router MLDv1 có mặt trên một liên kết, Querier PHẢI sử dụng phiên bản MLDv1 trên
mạng. Các router mong muốn tương thích với MLDv1 PHẢI có một tùy chọn cấu hình để hoạt
động trong chế độ MLDv1; nếu router MLDv1 có mặt trên 1 liên kết, người quản trị hệ thống
phải cấu hình một cách rõ ràng tất cả các router MLDv2 hoạt động trong chế độ MLDv1. Khi ở
trong chế độ MLDv1, Querier PHẢI định kỳ gửi đi các bản tin General Query bị cắt bỏ trường
Multicast Address (tức là chiều dài bản tin bằng 24 octet), và cũng NÊN cảnh báo nếu nhận
được bản tin Query MLDv2 (các cảnh báo như vậy phải được giới hạn tốc độ). Querier PHẢI
đưa giá trị trễ phản hồi tối đa vào trong trường Maximum Response Code, tức là thuật toán tính
giá trị được mô tả trong mục 8.1.3 phải không được sử dụng.

 Nếu một router không được cấu hình rõ ràng việc sử dụng MLDv1 và nhận được một bản tin
General Query MLDv1, nó NÊN ghi lại cảnh báo. Những cảnh báo này PHẢI được giới hạn tốc
độ.

11.3.2. Trường hợp có sự hiện diện của đối tượng nghe địa chỉ multicast MLDv1
Router MLDv2 có thể được đặt trong mạng mà các host chưa được hỗ trợ lên MLDv2. Để tương thích
với các host MLDv1, router MLDv2 PHẢI hoạt động trong chế độ tương thích với phiên bản 1. Các
router MLDv2 duy trì chế độ tương thích cho từng Multicast Address Record. Chế độ tương thích của

49
TCVN xxxx:2016
địa chỉ multicast được xác định từ biến chế độ tương thích địa chỉ multicast (Multicast Address
Compatibility Mode), có thể là 1 trong 2 trạng thái sau: MLDv1 hoặc MLDv2.

Chế độ tương thích địa chỉ multicast của một Multicast Address Record được thiết lập là MLDv1 bất cứ
khi nào router nhận được bản tin Report MLDv1 cho địa chỉ multicast đó. Tại cùng thời điểm, bộ đếm
thời gian biểu hiện host phiên bản cũ hơn cho một địa chỉ multicast được thiết lập bằng giá trị [kết thúc
thời gian thể hiện host phiên bản cũ hơn] giây. Bộ đếm thời gian này được thiết lập lại khi nhận một
bản tin Report MLDv1 mới cho địa chỉ multicast đó. Nếu bộ đếm thời gian biểu hiện host phiên bản cũ
hơn kết thúc, router sẽ chuyển chế độ tương thích địa chỉ multicast thành MLDv2 cho địa chỉ multicast
đó.

Chú ý rằng khi router chuyển chế độ tương thích địa chỉ multicast thành MLDv2 cho một địa chỉ
multicast, nó sẽ mất thời gian thu thập lại các thông tin trạng thái về nguồn cụ thể. Các thông tin về
nguồn cụ thể sẽ được xác định qua bản tin General Query tiếp theo, nhưng các nguồn nên chặn sẽ
không bị chặn cho tới [khoảng thời gian nghe địa chỉ multicast] sau đó.

Khi chế độ tương thích địa chỉ multicast là MLDv2, router hoạt động bằng cách sử dụng giao thức
MLDv2 cho địa chỉ multicast đó. Khi chế độ tương thích địa chỉ multicast là MLDv1, router sẽ dịch các
bản tin MLDv1 cho địa chỉ multicast đó thành các bản ghi MLDv2 tương ứng:

Bản tin MLDv1 Bản ghi MLDv2 tương ứng

------------------- -----------------------------------
Report IS_EX ( { } )
Done TO_IN ( { } )

Các bản tin mang bản ghi BLOCK MLDv2 được bỏ qua, vì là danh sách nguồn trong các bản tin chứa
bản ghi TO_EX () (tức là các bản ghi TO_EX () được đối xử như là TO_EX ( { } )). Mặt khác, Querier
tiếp tục gửi các bản tin Query MLDv2 bất kể chế độ tương thích địa chỉ multicast của nó.

12 Danh sách các bộ đếm thời gian, bộ đếm và giá trị mặc định của chúng

Hầu hết các bộ đếm thời gian này đều có thể cấu hình được. Nếu không sử dụng giá trị mặc định, thì
giá trị các bộ đếm này phải thống nhất giữa tất cả các nút trên một liên kết.

12.1 Biến Robustness

Biến Robustness cho phép hiệu chỉnh số gói tin có thể bị mất được dự đoán trước trên một liên kết.
Nếu một liên kết được dự đoán là có mất gói, giá trị của biến Robustness có thể được tăng lên. MLD là
ổn định với [biến Robustness] -1 gói tin mất. Giá trị của biến Robustness KHÔNG ĐƯỢC được bằng 0,
và KHÔNG NÊN bằng 1. Giá trị mặc định : 2.

12.2 Khoảng thời gian truy vấn

Khoảng thời gian truy vấn quy định khoảng thời gian giữa các bản tin General Query được Querier gửi
đi. Giá trị mặc định: 125 giây.

50
 TCVN xxxx:2016
Bằng cách thay đổi [khoảng thời gian truy vấn], người quản trị có thể hiệu chỉnh số lượng bản tin MLD
trên liên kết; giá trị này càng lớn sẽ làm cho các bản tin Query MLD được gửi ít thường xuyên hơn.

12.3 Khoảng thời gian phản hồi truy vấn

Trễ phản hồi tối đa được sử dụng để tính toán trường Maximum Response Code trong các bản tin
General Query định kỳ. Giá trị mặc định là 10 giây.

Bằng cách thay đổi [khoảng thời gian phản hồi truy vấn], người quản trị có thể hiệu chỉnh sự bùng phát
của các bản tin MLD trên liên kết; giá trị càng lớn làm cho lưu lượng càng ít bùng phát, vì các phản hồi
host được dàn trải trong một khoảng thời gian lớn hơn. Thời gian (theo giây) của [khoảng thời gian
phản hồi truy vấn] phải nhỏ hơn [khoảng thời gian truy vấn].

12.4 Khoảng thời gian lắng nghe địa chỉ multicast

Khoảng thời gian lắng nghe địa chỉ multicast (MALI) là khoảng thời gian trước khi một router multicast
quyết định không còn đối tượng nghe cho một địa chỉ multicast hoặc một nguồn cụ thể nào nữa trên
một liên kết. Giá trị này PHẢI bằng:

([biến Robustness] X [khoảng thời gian truy vấn]) + [khoảng thời gian phản hồi truy vấn].

12.5 Khoảng thời gian hiện diện Querier khác

Khoảng thời gian hiện diện Querier khác là tổng thời gian trước khi một router multicast quyết định
không còn router multicast khác ở trạng thái Querier. Giá trị mặc định PHẢI bằng:

([biến Robustness] X [khoảng thời gian truy vấn]) + 1/2 [khoảng thời gian phản hồi truy vấn].

12.6 Khoảng thời gian truy vấn khi khởi động

Khoảng thời gian truy vấn khi khởi động là thời gian giữa các bản tin General Query được gửi bởi
Querier khi khởi động. Giá trị mặc định: ¼ [khoảng thời gian truy vấn].

12.7 Số lượng truy vấn khi khởi động

Số lượng truy vấn khi khởi động là số các bản tin Query được gửi đi khi khởi động và cách nhau bởi
[khoảng thời gian truy vấn khi khởi động]. Giá trị mặc định: [biến Robustness].

12.8 Khoảng thời gian truy vấn đối tượng nghe cuối cùng

Khoảng thời gian truy vấn đối tượng nghe cuối cùng (gọi tắt là LLQI) là trễ phản hồi tối đa được sử
dụng để tính toán trường Maximum Response Code trong các bản tin Multicast Address Specific Query
gửi đi để hồi đáp lại các bản tin Done phiên bản 1. Đó cũng là trễ phản hồi tối đa được sử dụng để tính
toán trường Maximum Response Code trong bản tin Multicast Address and Source Specific Query. Giá
trị mặc định: 1000 (1 giây).

51
TCVN xxxx:2016
Chú ý rằng với các giá trị LLQI lớn hơn 32.768 giây, có thể được thể hiện bằng một tập hữu hạn các
giá trị tương ứng với các giá trị liên tiếp của trường Maximum Response Code. Khi chuyển đổi thời
gian được cấu hình sang giá trị trường Maximum Response Code, thì khuyến nghị sử dụng giá trị
chính xác nếu có thể, hoặc giá trị nhỏ hơn tiếp theo nếu giá trị được yêu cầu không thể thể hiện một
cách chính xác.

Giá trị này có thể được hiệu chỉnh để thay đổi “trễ rời nhóm” của liên kết. Giá trị này càng nhỏ sẽ càng
làm giảm thời gian phát hiện sự rời đi của đối tượng nghe cuối cùng cho một địa chỉ multicast hoặc
nguồn.

12.9 Số lượng truy vấn đối tượng nghe cuối cùng

Số lượng truy vấn đối tượng nghe cuối cùng (viết tắt là LLQC) là số bản tin Multicast Address Specific
Query được gửi đi trước khi router giả định rằng không còn đối tượng nghe cục bộ nào. LLQC cũng là
số lượng bản tin Multicast Address and Source Specific Query được gửi đi trước khi router giả định
rằng không còn đối tượng nghe nào đối với một nguồn cụ thể. Giá trị mặc định: bằng giá trị [biến
Robustness].

12.10 Thời gian truy vấn đối tượng nghe cuối cùng

Thời gian truy vấn đối tượng nghe cuối cùng (viết tắt là LLQT) là giá trị thời gian được thể hiện bằng:

[LLQI] X [LLQC].

Đây không phải là giá trị có thể thay đổi được, nhưng vẫn có thể được hiệu chỉnh bằng cách thay đổi
các thành phần của nó.

12.11 Khoảng thời gian báo cáo không theo thăm dò

Khoảng thời gian báo cáo không theo thăm dò là thời gian giữa các bản tin phát lại của bản tin Report
ban đầu ban đầu mà một nút thể hiện mối quan tâm tới một địa chỉ multicast. Giá trị mặc định: 1 giây.

12.12 Thời gian chờ cho Querier phiên bản cũ hơn

Thời gian chờ cho Querier phiên bản cũ hơn là khoảng thời gian chờ cho việc chuyển trạng thái của
một host ngược lại chế độ tương thích host MLDv2. Khi nhận được một bản tin Query MLDv1, các host
MLDv2 phải thiết lập bộ đếm thời gian cho Querier phiên bản 1 về giá trị [thời gian chờ cho Querier
phiên bản cũ hơn].

Giá trị này PHẢI bằng: [biến Robustness] X [khoảng thời gian truy vấn] + ([khoảng thời gian phản hồi
truy vấn]).

Trong đó, giá trị [khoảng thời gian truy vấn] là giá trị có trong bản tin Query cuối cùng nhận được.

52
 TCVN xxxx:2016
12.13 Khoảng thời gian chờ cho host phiên bản cũ hơn

Khoảng thời gian chờ cho host phiên bản cũ hơn là thời gian chờ cho việc chuyển trạng thái router
ngược lại chế độ tương thích địa chỉ multicast MLDv2 cho một địa chỉ multicast cụ thể. Khi nhận được
một bản tin Report MLDv1 cho địa chỉ multicast đó, router thiết lập bộ đếm thời gian host phiên bản 1
thành giá trị [khoảng thời gian chờ cho host phiên bản cũ hơn].

Giá trị này PHẢI bằng ([biến Robustness] X [khoảng thời gian truy vấn]) + ([khoảng thời gian phản hồi
truy vấn])

12.14 Cấu hình các bộ đếm thời gian

Phần này đưa ra các lời khuyên cho các nhà quản trị mạng về việc làm sao để hiệu chỉnh các cài đặt
cấu hình cho mạng của người quản trị. Những thực thi của router có thể hiệu chỉnh các cài đặt này một
cách linh động dựa trên việc thay đổi các thuộc tính đặc trưng của từng mạng.

12.14.1 Biến Robustness

Biến Robustness cho phép hiệu chỉnh số gói tin có thể bị mất được ước lượng trên một liên kết.
MLDv2 là ổn định với giá trị [biến Robustness]-1 gói tin bị mất, ví dụ, nếu biến Robustness được thiết
lập về giá trị mặc định bằng 2, MLDv2 là ổn định với một gói duy nhất bị mất nhưng có thể hoạt động
không hoàn hảo nếu có nhiều mất gói xảy ra. Trên các liên kết có mất gói, giá trị của biến Robustness
sẽ được tăng lên để cho phép ước lượng mất gói có thể xảy ra. Tuy nhiên, việc tăng giá trị biến
Robustness này cũng làm tăng trễ rời nhóm của một liên kết (thời gian giữa thời điểm đối tượng nghe
cuối cùng ngừng theo dõi một nguồn hoặc một địa chỉ và thời điểm lưu lượng ngừng chuyển tiếp).

12.14.2 Khoảng thời gian truy vấn

Tổng lưu lượng MLD theo định kỳ là tỷ lệ nghịch với khoảng thời gian truy vấn. Khoảng thời gian truy
vấn càng lâu dẫn tới tổng lưu lượng MLD càng thấp. Giá trị của khoảng thời gian truy vấn PHẢI lớn
hơn hoặc bằng trễ phản hồi tối đa được sử dụng để tính toán trường Maximum Respond Code trong
các bản tin General Query.

12.14.3 Trễ phản hồi tối đa

Tính ổn định của lưu lượng MLD là tỷ lệ nghịch với trễ phản hồi tối đa. Giá trị trễ phản hồi tối đa càng
lâu sẽ dàn trải bản tin Report trong một khoảng thời gian càng lâu. Tuy nhiên, trễ phản hồi tối đa càng
lâu trong các bản tin Multicast Address Specific Query và bản tin Multicast Address and Source
Specific Query sẽ mở rộng trễ rời nhóm (thời gian giữa thời điểm đối tượng nghe cuối cùng ngừng theo
dõi một nguồn hay một địa chỉ multicast và thời điểm lưu lượng ngừng chuyển tiếp). Tốc độ dự kiến
của các bản tin Report có thể được tính toán bằng cách chia giá trị trễ phản hồi tối đa cho số lượng đối
tượng báo cáo được ước lượng. Trễ phản hồi tối đa có thể được tính toán một cách linh động cho từng
bản tin Query bằng cách sử dụng số lượng đối tượng báo cáo được dự kiến như sau:

53
TCVN xxxx:2016

Loại bản tin Query Số lượng bản tin Report được dự kiến
------------------------- ---------------------------------------------------

Bản tin General Query Tất cả các nút trên liên kết

Bản tin Multicast Address Specific Query Tất cả các nút trên liên kết thể hiện mối quan tâm tới địa
chỉ multicast

Bản tin Multicast Address and Source Tất cả các nút trên liên kết thể hiện mối quan tâm tới
Specific Query nguồn và địa chỉ multicast

13 Các vấn đề an toàn bảo mật

Dưới đây là các trường hợp khác nhau của từng loại bản tin bị giả mạo. Chú ý rằng trước khi xử lý một
bản tin MLD, nút sẽ xác minh rằng địa chỉ nguồn của bản tin có phải một địa chỉ link-local hợp lệ không,
trường Hop Limit có được thiết lập bằng 1 không, và tùy chọn Router Alert có được thể hiện trong mào
đầu Hop-by-Hop Options của gói tin IPv6 không. Nếu bất kỳ kiểm tra nào trong các kiểm tra này xảy ra
lỗi, gói tin sẽ bị loại bỏ. Điều này bảo vệ nút MLDv2 khỏi hoạt động trên các bản tin MLD bị giả mạo có
nguồn gốc off-link. Do đó phần tiếp theo chỉ đề cập tới các ảnh hưởng của giả mạo on-link.

13.1 Bản tin Query

Bản tin Query bị giả mạo từ một máy với địa chỉ IPv6 thấp hơn so với Querier hiện tại sẽ làm cho
nhiệm vụ Querier được chỉ định cho đối tượng giả mạo. Nếu sau đó đối tượng giả mạo không gửi đi
bất kỳ bản tin Query nào, bộ đếm thời gian cho Querier khác của các router khác sẽ kết thúc và một
router sẽ tiếp tục vai trò Querier. Trong suốt thời gian này, nếu Querier bỏ qua các bản tin Done, lưu
lượng có thể sẽ chuyển sang những địa chỉ multicast không có đối tượng nghe trong thời gian lên đến
[khoảng thời gian đối tượng nghe địa chỉ multicast].

Bản tin Query phiên bản 1 bị giả mạo sẽ đặt các đối tượng nghe MLDv2 trên liên kết đó sang chế độ
tương thích host MLDv1. Kịch bản này có thể được tránh bằng cách sử dụng các host MLDv2 có tùy
chọn cấu hình bỏ qua các bản tin phiên bản 1 một cách hoàn toàn.

Một tấn công DoS trên một nút có thể được tiến hành thông qua các bản tin Multicast Address and
Source Specific Query bị giả mạo. Kẻ tấn công có thể tìm ra trạng thái nghe của một nút cụ thể với một
bản tin General Query. Sau đó, chúng có thể gửi đi một lượng lớn các bản tin Multicast Address and
Source Specific Query, mỗi bản tin này có một danh sách nguồn lớn hoặc/ và trễ phản hồi tối đa dài.
Mỗi nút sẽ phải chứa và duy trì các nguồn được quy định trong tất cả các bản tin Query đó cho tới khi
chúng gửi đi các phản hồi được làm trễ. Điều này có thể tiêu tốn cả về bộ nhớ và CPU khi ghi lại các
nguồn trong danh sách nguồn của các bản tin Query thành công.

54
 TCVN xxxx:2016
Để bảo vệ lại các tấn công DoS như vậy, việc thực thi ngăn xếp nút sẽ giới hạn số lượng bản tin
Multicast Address and Source Specific Query cho từng địa chỉ multicast trong khoảng thời gian này,
và/hoặc chỉ ghi lại một số hữu hạn các nguồn.

13.2 Các bản tin Current State Report

Bản tin Report bị giả mạo làm cho các router multicast nghĩ rằng có các đối tượng nghe một địa chỉ
multicast trên một liên kết trong khi không tồn tại đối tượng nào. Tuy nhiên, vì việc nghe một địa chỉ
multicast trên một host là một hành động không cần cấp quyền, nên người sử dụng có thể đạt được
các kết quả tương tự mà không giả mạo bất kỳ bản tin nào.

Bản tin Report phiên bản 1 bị giả mạo có thể đặt router vào trong chế độ tương thích địa chỉ multicast
MLDv1 cho một địa chỉ multicast cụ thể, nghĩa là router sẽ bỏ qua các bản tin trạng thái nguồn cụ thể
MLDv2. Điều này có thể làm cho lưu lượng chuyển từ những nguồn không mong muốn trong thời gian
lên đến [khoảng thời gian đối tượng nghe địa chỉ multicast]. Điều này có thể được giải quyết bằng cách
thiết lập các router có một cấu hình chuyển mạch cho phép bỏ qua các bản tin phiên bản 1 một cách
hoàn toàn. Điều này phá vỡ tính tương thích tự động với các host phiên bản 1, nên nó sẽ chỉ được sử
dụng trong trường hợp việc lọc nguồn là cần thiết.

13.3 Bản tin State Change Report

Bản tin State Change Report bị giả mạo sẽ làm cho Querier gửi đi các bản tin Multicast Address
Specific Query và bản tin Multicast Address and Source Specific Query cho một nguồn nhất định dưới
dạng hỏi đáp. Điều này gây ra những xử lý bổ sung trên mỗi router và trên mỗi đối tượng nghe của địa
chỉ multicast nhưng không thể gây ra mất lưu lượng mong muốn.

55
TCVN xxxx:2016
Phụ lục A

(Quy định)

Lý do thiết kế căn bản

A.1. Sự cần thiết của các bản tin thay đổi trạng thái
MLDv2 chỉ rõ 2 loại bản tin Report: bản tin Current State Report và bản tin State Change Report. Phần
này mô tả lý do căn bản cho sự cần thiết của cả hai loại bản tin Report trên.

Router cần phân biệt các bản tin Report được sử dụng cho việc phản hồi lại các bản tin Query cho việc
thay đổi trạng thái của từng giao diện. Các bản tin Report được sử dụng chủ yếu để làm mới lại trạng
thái đang tồn tại của router, thì không gây ra sự chuyển đổi trạng thái tại các router. Các bản tin Report
được gửi để phản hồi các thay đổi trong trạng thái từng giao diện, thì yêu cầu router có các xử lý để hồi
đáp lại bản tin Report đã nhận (xem phần 7.4).

Việc không có khả năng phân biệt giữa hai loại bản tin Report sẽ làm cho router xử lý tất cả các bản tin
Report giống như các thay đổi có khả năng xảy ra trong trạng thái và có thể làm tăng thêm các xử lý tại
router cũng như làm tăng lưu lượng MLD trên liên kết.

A.2. Việc ngăn chặn host

Trong MLDv1, một host sẽ không gửi đi bản tin Report đang ở trạng thái chờ nếu một bản tin tương tự
đã được gửi đi bởi một đối tượng nghe khác trên liên kết. Trong MLDv2, việc ngăn chặn các bản tin
Report đã bị gỡ bỏ. Các ý sau giải thích rõ ràng tính năng này.

1. Các router có thể muốn theo dõi trạng thái đối tượng nghe multicast theo từng host trên một
giao diện. Điều này sẽ cho phép router thực thi tính năng rời nhóm nhanh (ví dụ, cho cơ chế
điều khiển tắc nghẽn multicast được phân tầng), cũng như theo dõi trạng thái đối tượng nghe
cho các mục đích bảo mật hoặc thống kê. Tiêu chuẩn hiện tại không yêu cầu router thực thi việc
theo dõi từng host. Tuy nhiên, việc không ngăn chặn các thông báo từ host trong MLDv2 tạo ra
khả năng thực thi quyền sở hữu hoặc các cách xử lý chính xác trong tương lai của router (khi
đó, router có khả năng hỗ trợ tính năng theo dõi từng host), trong khi tương tác với các đối
tượng nghe và router MLDv2 đang thực thi tiêu chuẩn này này.

2. Việc ngăn chặn bản tin Report không hoạt động trên mạng LAN được bắc cầu (bridged LAN).
Nhiều thiết bị bắc cầu hoặc các bộ chuyển mạch tầng 2/ tầng 3 thực thi MLD snooping không
chuyển tiếp các bản tin MLD qua các phần tử LAN để hạn chế việc ngăn chặn báo cáo đối
tượng multicast.

3. Việc chấm dứt ngăn chặn bản tin Report khiến host phải xử lý ít bản tin hơn; điều này dẫn tới
việc máy thực thi có trạng thái đơn giản hơn.

4. Trong MLDv2, một bản tin Report đơn lẻ gộp nhiều Multicast Address Record để giảm số lượng
gói tin gửi đi. Để so sánh, phiên bản MLDv1 yêu cầu rằng mỗi địa chỉ multicast được báo cáo
trong một bản tin riêng rẽ.

56
 TCVN xxxx:2016
A.3. Chuyển chế độ lọc của router từ EXCLUDE sang INCLUDE
Nếu trên một liên kết có các nút ở các chế độ EXCLUDE và INCLUDE với một địa chỉ multicast độc
lập, router phải ở chế độ EXCLUDE (mục 7.2.1). Trong chế độ EXCLUDE, router chuyển tiếp lưu
lượng từ các nguồn nằm ngoài danh sách EXCLUDE. Nếu tất cả các nút trong chế độ EXCLUDE dừng
nghe hoặc không còn khả dụng, router phải được chuyển ngược về chế độ INCLUDE một cách liền
mạch, mà lưu lượng tới các đối tượng nghe đang tồn tại không bị gián đoạn.

Một trong nhiều phương án để thực thi điều này là cho phép các router theo dõi tất các nguồn mà các
nút đang ở trong chế độ INCLUDE đang nghe, ngay cả khi router ở trong chế độ EXCLUDE. Nếu bộ
đếm thời gian cho chế độ lọc cho một địa chỉ multicast kết thúc (tức là không còn nút nào trong chế độ
EXCLUDE trên liên kết) thì sau đó router sẽ chuyển sang chế độ INCLUDE một cách liền mạch; các
nguồn từ danh sách được yêu cầu sẽ chuyển sang danh sách INCLUDE, trong khi các nguồn trong
danh sách EXCLUDE sẽ bị xóa bỏ.

57
TCVN xxxx:2016
Phụ lục B

(Tham khảo)

Bảng đối chiếu nội dung tương đương của TCVN và tài liệu RFC 3810

TCVN Tài liệu RFC 3810

1 Phạm vi áp dụng

2 Tài liệu viện dẫn

3 Thuật ngữ và định nghĩa

4 Chữ viết tắt

5 Tổng quan giao thức Section 2

5.1 Thiết lập trạng thái nghe multicast trên các đối tượng nghe
Section 2.1
địa chỉ multicast

5.2 Việc trao đổi các bản tin giữa Querier và các nút nghe Section 2.2

5.3 Thiết lập trạng thái đối tượng nghe địa chỉ multicast trên
Section 2.3
router multicast

6 Giao diện dịch vụ cho việc yêu cầu nhận IP Multicast Section 3

7 Trạng thái nghe multicast được duy trì bởi các nút Section 4

7.1 Trạng thái từng socket Section 4.1

7.2 Trạng thái từng giao diện Section 4.2

8 Các định dạng bản tin Section 5

8.1 Bản tin Multicast Listener Query Section 5.1

8.2 Bản Tin Multicast Listener Report Section 5.2

9 Mô tả giao thức đối với các đối tượng nghe địa chỉ
Section 6
multicast

9.1 Xử lý theo sự thay đổi của trạng thái từng giao diện Section 6.1

9.2 Xử lý khi nhận bản tin Query Section 6.2

58
 TCVN xxxx:2016

9.3 Xử lý khi bộ đếm thời gian kết thúc Section 6.3

10 Các mô tả của giao thức cho router multicast Section 7

10.1 Các điều kiện cho những bản tin Query Section 7.1

10.2 Trạng thái MLD được duy trì bởi các router multicast Section 7.2

10.3 Các quy tắc chuyển tiếp nguồn MLD cụ thể Section 7.3

10.4 Xử lý khi tiếp nhận bản tin Report Section 7.4

10.5 Chuyển sang các chế độ lọc router Section 7.5

10.6 Hành động khi tiếp nhận bản tin Query Section 7.6

11 Tính tương thích với MLDv1 Section 8

11.1 Sự khác biệt về phiên bản của bản tin Query Section 8.1

11.2 Cách xử lý của đối tượng nghe địa chỉ multicast Section 8.2

11.3 Cách xử lý của router multicast Section 8.3

12 Danh sách các bộ đếm thời gian, bộ đếm và giá trị mặc định
Section 9
của chúng

12.1 Biến Robustness Section 9.1

12.2 Khoảng thời gian truy vấn Section 9.2

12.3 Khoảng thời gian phản hồi truy vấn Section 9.3

12.4 Khoảng thời gian lắng nghe địa chỉ multicast Section 9.4

12.5 Khoảng thời gian hiện diện Querier khác Section 9.5

12.6 Khoảng thời gian truy vấn khi khởi động Section 9.6

12.7 Số lượng truy vấn khi khởi động Section 9.7

12.8 Khoảng thời gian truy vấn đối tượng nghe cuối cùng (LLQI) Section 9.8

12.9 Số lượng truy vấn đối tượng nghe cuối cùng (LLQC) Section 9.9

59
TCVN xxxx:2016

12.10 Thời gian truy vấn đối tượng nghe cuối cùng (LLQT) Section 9.10

12.11 Khoảng thời gian báo cáo không theo thăm dò Section 9.11

12.12 Thời gian chờ của Querier phiên bản cũ hơn Section 9.12

12.13 Khoảng thời gian chờ host phiên bản cũ hơn Section 9.13

12.14 Cấu hình các bộ đếm thời gian Section 9.14

13 Các vấn đề bảo mật Section 10

13.1 Bản tin Query Section 10.1

13.2 Các bản tin Current State Report Section 10.2

13.3 Các bản tin State Change Report Section 10.3

Phụ lục A (quy định) APPENDIX A

Phụ lục B (tham khảo)

Thư mục tài liệu tham khảo

60
 TCVN xxxx:2016
Thư mục tài liệu tham khảo

[1] RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6.

[2] RFC 2710 Multicast Listener Discovery (MLD) for IPv6.

[3] RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification.

61