Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 90 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
90
Dung lượng
828,88 KB
Nội dung
BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC GIAO THÔNG VẬN TẢI HOÀNG THỊ NGOAN NGHIÊN CỨU CƠ CHẾ PHIÊN DỊCH MULTICAST IPv4 SANG IPv6 Chuyên ngành: Kỹ thuật điện tử Mã số: 60.52.70 Khóa: 16 - Cơ sở LUẬN VĂN THẠC SĨ KỸ THUẬT CÁN BỘ HƯỚNG DẪN: TS TRỊNH QUANG KHẢI TP.Hồ Chí Minh, năm 2011 LUẬN VĂN THẠC SĨ KỸ THUẬT LỜI NÓI ĐẦU LỜI NÓI ĐẦU Mạng Internet sử dụng giao thức Internet (IP) làm sở truyền thơng để từ thiết bị kết nối với mạng Internet dựa giao thức IP Mạng Internet mạng chuyển mạch gói, tất thơng tin truyền mạng Internet đóng thành gói gói truyền mạng, định tuyến phân phát đến thiết bị thu nhận Trong gói IP ln chứa địa nơi gửi địa nơi nhận, gọi địa nguồn địa đích hay gọi chung địa IP Một địa IP thông thường phải chứa thông tin nhận dạng vị trí thiết bị, dựa vào thơng tin mà gói IP định tuyến đến đích cách xác Hiện mạng Internet sử dụng IP phiên hay cịn gọi IPv4 Một gói IPv4 sử dụng 32 bit để làm địa chỉ, IPv4 cung cấp không gian địa 232, nhiên phần không gian địa lại sử dụng cho số mục đích đặc biệt khác nên số lượng địa IP thực phân phát cho thiết bị bị giảm xuống, điều đồng nghĩa với việc số lượng thiết bị kết nối vào mạng Internet bị giới hạn Theo xu hướng nguồn địa IP khai thác hết vào năm 2012 Một phiên IP phát triển từ năm 90, IPv6 IPv6 cung cấp không gian địa 2128 địa Tuy nhiên IPv4 IPv6 có nhiều điểm khác nên chúng khơng tương thích với nhau, nghĩa dịch vụ IPv4 hoạt động mạng IPv6 túy Việc kết nối mạng IPv4 IPv6 phải thông qua trung gian việc phiên dịch hai giao thức CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan LUẬN VĂN THẠC SĨ KỸ THUẬT LỜI NÓI ĐẦU Trước đây, hai thiết bị mạng IP liên lạc với phương thức truyền thông đơn hướng (unicast) Phương thức truyền thơng cho phép gói tin phát từ tin truyền đến nơi nhận tin nhất, hay gọi kết nối – Đối với phương thức truyền thơng gói tin nhận xử lý host đơn mạng Truyền thông đơn hướng làm xuất nhiều gói tin giống truyền đường truyền hay đường truyền song song từ nguồn phát đến nhiều nguồn thu khác Khi số lượng nguồn thu tăng lên số lượng gói tin giống tăng lên gây lãng phí đường truyền Truyền thông đa hướng (multicast) xuất giải vấn đề unicast Phương thức truyền thơng cho phép gói tin truyền đến nhiều đích khác hay cịn gọi kết nối – nhiều Nguồn phát phát gói tin lần nhất, gói tin truyền đến nhiều nguồn thu khác mạng Một gói tin multicast khơng bị giới hạn số lượng nguồn thu Một dịch vụ quan trọng multicast truyền hình IP (IPTV) IPTV cung cấp dịch vụ truyền hình số qua mạng IP Các dịch vụ IPTV bao gồm: dịch vụ truyền hình theo yêu cầu (VoD) kênh truyền hình trực tiếp qua mạng IP IPTV xây dựng dựa tảng multicast, kênh truyền hình trực tiếp phát từ nguồn phát thu nhiều nguồn thu khác Nếu IPTV sử dụng uincast mạng phải yêu cầu số lượng nguồn phát khổng lồ lượng băng thơng vơ hạn cho đường truyền, điều khó thực IPTV sử dụng phương thức multicast giúp làm giảm CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan LUẬN VĂN THẠC SĨ KỸ THUẬT LỜI NÓI ĐẦU số lượng nguồn phát băng thông đường truyền mà đáp ứng số lượng thuê bao lớn mạng Hầu hết dịch vụ Internet hoạt động mạng IPv4, số dịch vụ hoạt động mạng IPv6 túy Tuy nhiên đa số dịch vụ IPv4 hoạt động mạng IPv6 sử dụng dịch vụ phiên dịch tương thích mạng Mục tiêu luận văn xây dựng phiên dịch dịch vụ multicast IPv4 IPv6 Nói cách khác, dịch vụ phiên dịch giúp cho host IPv6 kết nối với nhóm host multicast IPv4 Bộ phiên dịch hỗ trợ tất dịch vụ multicast tại, khơng u cầu chuyển đổi từ phía phát IPv4 phía thu IPv6 Tuy nhiên phạm vi nghiên cứu luận văn không đề cập đến việc phiên dịch dịch vụ đặc biệt phiên dịch unicast, luận văn triển khai phiên dịch dịch vụ quan trọng multicast IPTV Luận văn gồm có chương Chương 1: Trình bày kiến thức kỹ thuật sở luận văn Chương 2: Xác định tiêu chuẩn yêu cầu trình phiên dịch, xây dựng phiên dịch multicast IPv4 – IPv6 Chương 3: Phân tích kết phiên dịch so với tiêu chuẩn yêu cầu đưa chương Cuối phần kết luận hướng phát triển đề tài CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 Chương Chương LÝ THUYẾT CƠ SỞ 1.1 Giới thiệu Hiện mạng Internet sử dụng giao thức IPv4, nhiên tương lai gần chuyển sang IPv6 Chính khác biệt hai phiên giao thức IP làm cho trình chuyển đổi mạng gặp nhiều khó khăn Q trình chuyển đổi khơng thể thực lúc mà phải thực nhiều giai đoạn Vấn đề để dịch vụ có mạng IPV4 cung cấp dịch vụ hai mạng IPv4 IPv6 thời gian chuyển đổi Để giải vấn đề phương án tốt sử dụng phiên dịch Trong phạm vi luận văn xét đến vấn đề phiên dịch multicast Multicast phương thức truyền thông đa hướng với nhiều ưu điểm khắc phục hạn chế phương thức unicast trước Multicast xuất hiện, với địa multicast giao thức liên quan đến vấn đề định tuyến multicast Dịch vụ quan trọng multicast dịch vụ truyền hình IP hay IPTV IPTV cho phép truyền tải tín hiệu truyền hình IP theo hai phương pháp: truyền tải thời gian thực RTP truyền dẫn trực tiếp UDP Nội dung chương mô tả khác biệt hai phiên giao thức IP, địa multicast, giao thức liên quan đến định tuyến multicast, phương pháp truyền tải IPTV Bên cạnh đó, chương cịn đề cập đến phiên dịch hạn chế phiên dịch việc phiên dịch multicast đặc biệt truyền tải IPTV CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 1.2 Chương Sự khác IPv6 IPv4 IPv6 giao thức IP phiên mới, xây dựng sở giao thức IP phiên cũ IPv4 So sánh IPv6 IPv4 thấy có nhiều điểm khác biệt 1.2.1 Phần mào đầu Cấu trúc phần mào đầu IPv4: Hình 1.1: Phần mào đầu IPv4 Phần mào đầu IPv4 bao gồm trường thông tin sau: Version: bit, chứa thông tin phiên giao thức, phiên Header length: bit, độ dài phần header Type of service: chứa thông tin loại dịch vụ gói tin, bao gồm thông tin về: độ ưu tiên, độ trễ, băng thông, độ tin cậy, chi phí mong muốn gói tin CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 Chương Total length: chiều dài gói liệu Identification: số nhận dạng đoạn phân mảnh Flags: bit cờ xác định gói liệu có bị phân mảnh hay khơng có phân mảnh đoạn có phải đoạn cuối hay khơng Fragment offset: vị trí đoạn phân mảnh tính từ đầu gói liệu, tính byte Time to live: xác định số router tối đa mà gói liệu phép qua Protocol: xác định kiểu giao thức lớp cao Header checksum: kiểm tra lỗi header Source address: địa nguồn Destination address: địa đích Options: trường tùy chọn thông số kỹ thuật Padding: byte đệm CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 Chương Cấu trúc phần mào đầu IPv6: Hình 1.2: Phần mào đầu IPv6 Phần mào đầu IPv6 bao gồm trường thông tin sau: Version: bit, xác định phiên giao thức IP, phiên Traffic class: bit, xác định lớp ưu tiên khác Flow label: 20 bit, dùng cho nút nguồn để xác định gói có luồng hay khơng Payload length: 16 bit, độ dài phần tải trọng gói Next header: bit, xác định router mở rộng header tiếp theo, header không mở rộng dùng để xác định header lớp Hop limit: xác định số hop tối đa Source address: 128 bit, địa nguồn Destination address: 128 bit, địa đích So với IPv4, phần mào đầu IPv6 bỏ nhiều trường thông tin Trong header IPv6, trường thông tin tùy chọn phân mảnh di chuyển sang phần header riêng biệt gắn phía sau header IP Header CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 Chương lớp truyền tải nội dung gói tin đặt vị trí cuối sau phần header riêng biệt Trong header IPv6, trường thông tin độ dài header bỏ qua độ dài header cố định 40 byte Trường thông tin kiểm tra lỗi checksum bỏ qua kiểm tra giao thức lớp TCP UDP Trong giao thức lớp truyền tải UDP trường tin checksum ln sử dụng gói IP IPv6 không sử dụng (thiết lập 0) gói IP IPv4 1.2.2 Kỹ thuật phân mảnh đơn vị truyền dẫn tối đa MTU MTU đơn vị truyền dẫn tối đa, giới hạn kích thước tối đa gói mà truyền qua mạng khơng bị phân mảnh Đối với IPv4 gói tin kích thước nhỏ 68 byte khơng bị phân mảnh truyền qua link, IPv6 kích thước tăng lên 1280 byte IPv6 thay đổi trình thực việc phân mảnh mạng Đối với mạng IPv4 tất router nằm đường dẫn từ nguồn đến đích thực chia nhỏ gói có kích thước lớn MTU link Đối với mạng IPv6 router khơng quyền phân nhỏ gói Khi nhận gói có kích thước lớn MTU link router tiến hành gửi tin thông báo lỗi ICMPv6 ngược nguồn phát mang nội dung “Gói lớn” Khi nhận tin báo lỗi này, phía nguồn phát tiến hành phân nhỏ gói thành đoạn nhỏ gắn vào đầu đoạn tiêu đề phân mảnh (fragment header) Căn vào tiêu đề mà phía thu tập hợp lại gói tin ban đầu từ đoạn nhỏ nhận CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 Chương Trong mạng IPv4, host cấm phân mảnh gói gửi host thiết lập cờ DF (cờ không phân mảnh – Don’t Fragment) phần tiêu đề gói Trong trường hợp này, kích thước gói lớn MTU link router nhận có quyền hủy gói gửi ngược host nguồn tin ICMP với nội dung “Khơng thể tới đích” tin báo lỗi “Cần phân mảnh thiết lập cờ DF” Cờ DF sử dụng trình phát MTU đường dẫn (PMTUD) PMTUD trình tìm kiếm MTU nhỏ link đường dẫn làm MTU đường dẫn, để gói tin có kích thước nhỏ MTU đường dẫn truyền qua tất link đường dẫn không bị phân mảnh Một host tiến hành PMTUD, gửi gói tin với cờ DF thiết lập Khi gặp link có MTU nhỏ gói tin router hủy gói tin gửi cho host tin ICMP báo lỗi với nội dung “cần thiết phải phân mảnh” có chứa thơng tin MTU link Khi nhận ICMP host giảm kích thước gói xuống theo MTU link gửi Quá trình lặp lại kích thước gói giảm xuống đến MTU nhỏ link đường dẫn, MTU nhỏ MTU đường dẫn Tuy nhiên, router IPv4 không gửi tin ICMP đáp ứng cho gói tin multicast, gói multicast có kích thước lớn MTU link tự động bị bỏ qua âm thầm Nhưng mạng IPv6 router phép gửi ICMP đáp ứng cho gói multicast, PMTUD thực với gói multicast 1.2.3 Chất lượng dịch vụ Trong phần tiêu đề gói IPv4 có trường tin Type of Service bit mang thông tin dịch vụ khác thơng báo nghẽn Trong IPv6 CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan 72 Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 Chương Người quản trị cài đặt nhiều hệ thống phiên dịch cho mạng cấu hình định tuyến anycast cho phiên dịch giống chế phiên dịch 6-4 hay chế phiên dịch Teredo Tất phiên dịch sử dụng tiền tố unicast IPv6 mạng Các phiên dịch có địa RP anycast, địa nhúng vào tiền tố ASM IPv6 Với việc thay định tuyến anycast trước đó, nguồn thu IPv6 ln sử dụng phiên dịch gần mạng Việc bố trí phiên dịch giúp cải tiến trình định tuyến đặc biệt nguồn thu multicast IPv6 gần nguồn multicast IPv4 Định tuyến anycast cung cấp chế dự phịng đơn giản khơng tức Nếu phiên dịch bị lỗi, phiên dịch khác sử dụng sau cấu trúc liên kết định tuyến PIM unicast hội tụ Tốc độ hội tụ phụ thuộc vào việc thực định tuyến PIM unicast Bởi phiên dịch tiếp cận tất nguồn IPv4 nên việc sử dụng nhiều phiên dịch với định tuyến unicast không yêu cầu chia sẻ thông tin nguồn IPv4 hoạt động Vì phiên dịch không cần thiết hỗ trợ phương thức RP-anycast PIM Tuy nhiên nhóm IPv6 gửi thơng tin đến nhóm dịch việc sử dụng phương thức RPanycast PIM cần thiết Bằng cách sử dụng tiền tố unicast IPv6 địa RP anycast toàn cầu, việc định tuyến anycast sử dụng để tạo khả mở rộng phiên dịch multicast tồn cầu Tuy nhiên trước thành lập hệ thống phiên dịch multicast tồn cầu phiên dịch phải cải tiến để phiên dịch phạm địa nêu mục 2.7.2 CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan 73 Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 Chương Nếu tiền tố anycast dành cho phiên dịch chuẩn hóa, ứng dụng multicast IPv6 tương lai tăng cường để sử dụng tiền tố phiên dịch để gia nhập nhóm IPv4 kết nối đến mạng có kết nối IPv6 3.4 Đánh giá theo yêu cầu giao tiếp Việc cài đặt phiên dịch vào mạng router PIM yêu cầu thay đổi nhỏ cấu hình router Một phiên dịch phải có IPv4 IPv6, PIM-SM IGMPv3 phải kích hoạt router lân cận có kết nối đến phiên dịch Hơn nữa, tiền tố unicast IPv6 đại diện cho nguồn IPv4 phải định tuyến đến phiên dịch mạng IPv6 Tuy nhiên, phiên dịch sử dụng tiền tố RP nhúng IPv6 để đại diện cho nhóm ASM IPv4 mạng IPv6 khơng cần điều chỉnh cấu hình router PIM Việc truyền dẫn IPTV sử dụng MPEG-2 UDP phiên dịch tốt Tuy nhiên IPTV truyền dẫn sử dụng RTP mơ tả mục 1.6.1 đầu thu IPv6 gửi tin báo cáo đầu thu RTCP Việc gửi tin RTCP khơng thể thực u cầu đường dẫn ngược khơng có giá trị, phiên dịch khơng hỗ trợ unicast không hỗ trợ phiên dịch IPv4 – IPv6 Cũng mà ứng dụng yêu cầu đường dẫn ngược bị từ chối Các ứng dụng yêu cầu đường dẫn ngược gửi địa IP phần tải trọng gói, phần tải trọng gói khơng thay đổi phiên dịch, địa IP phần tải trọng gói khơng phiên dịch Vì ứng dụng sử dụng kênh thông tin bổ sung với host khác không làm việc với luồng multicast dịch Hơn để tạo đường dẫn ngược CBHD: TS Trịnh Quang Khải HVTH: Hồng Thị Ngoan 74 Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 Chương phải có thêm ALG (Application Level Gateway) để thay đổi phần tải trọng gói 3.5 Đánh giá theo ràng buộc thuộc tính Bộ phiên dịch yêu cầu chạy server Linux Red Hat Enterprise 64 bit Bởi phiên dịch khơng sử dụng tính đặc biệt Ret Hat nên phiên dịch chạy phiên Linux đại hỗ trợ trình biên dịch C++ Bộ phiên dịch khơng có u cầu phần cứng cụ thể MRD6 nơi thực phiên dịch hoạt động Linux nhúng Bởi phiên dịch sử dụng socket PF_PACKET Linux để nhận gói multicast IPv4 nên phiên dịch hoạt động Linux Bởi phiên dịch không yêu cầu di chuyển đến hệ thống khác nên việc sử dụng API không gây ảnh hưởng Nếu phiên dịch có khả di chuyển mạng phải sử dụng API di động để nhận gói tin Thư viện PCAP cung cấp API di động để gửi nhận gói tin lớp liên kết Tuy nhiên module MFA ICMPv6 MRD6 sửa đổi để sử dụng thư viện PCAP, hai thành phần MRD6 phụ thuộc vào socket PF_PACKET Linux API 3.6 Đánh giá theo thuật toán phân mảnh Như đề cập mục 3.5, phiên dịch thực phân mảnh gói IPv4 bất chấp cờ phân mảnh DF phần tiêu đề gói Bộ phiên dịch trì thơng tin MTU đường dẫn IPv6 cho tất địa đích multicast CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan 75 Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 Chương Thông tin MTU sử dụng để phân mảnh gói tin cách tối ưu Về bản, phiên dịch phát MTU IPv6 thay cho nguồn gửi IPv4 Bộ phiên dịch giảm bớt MTU địa đích multicast sau nhận tin ICMPv6 Packet Too Big Do gói tin có kích thước lớn mà router nhận sẻ bị hủy sau router gửi thơng báo báo lỗi ICMPv6 Packet Too Big Điều làm tăng thời gian trễ gia nhập nguồn thu có MTU thấp gói tin bị hủy bỏ đường truyền Theo thảo luận mục 3.3.3, thời gian trễ gia nhập phụ thuộc vào số lượng hop router nguồn phát nguồn thu Do việc tăng thời gian trễ gia nhập nguồn thu có MTU thấp khắc phục cách cài đặt phiên dịch vị trí hợp lý để có hop tham gia trình gia nhập Một lợi ích thuật tốn phân mảnh gói tin bị phân mảnh cần thiết Điều làm tăng hiệu giảm xác suất gói mạng IPv6 Hơn việc phân mảnh gói IPv6 thực phiên dịch khơng hiển thị nguồn thu IPv4 Do cơng việc nhóm IPv4 ban đầu không thay đổi Việc phân mảnh làm tăng tỷ lệ gói đoạn đơn dẫn đến gói Theo mơ tả mục 2.10.4, phiên dịch phải tạo giá trị Identification đặc biệt cho gói tin có cờ DF thiết lập Để chắn giá trị Identification gói tin dịch đặc biệt nhất, phiên dịch sử dụng giá trị khác cho 16 bit cao Identification 16 bit cao Identification không thiết lập gói IPv4 ban đầu CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan 76 Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 Chương Như giá trị nhận mạng IPv6 Nhưng vấn đề nảy sinh gói tin dịch phiên dịch ngược trở lại mạng IPv4 16 bit cao loại bỏ phiên dịch Tuy nhiên tình gặp, nhóm IPv4 gia nhập trực tiếp mà không cần thông qua hai lần phiên dịch 3.7 Ý nghĩa việc sử dụng IGMP để gia nhập nhóm IPv4 Bộ phiên dịch sử dụng IGMPv3 TCP/IP Linux để gia nhập nhóm IPv4 IGMP lựa chọn thay cho PIM sử dụng PIM IPv4 yêu cầu thay đổi mở rộng MRD6 Việc lựa chọn IGMP làm nảy sinh số giới hạn so với PIM Việc sử dụng IGMP Linux tạo giới hạn số lượng nhóm multicast IPv4 sử dụng socket gia nhập Bởi phiên dịch sử dụng gói UDP đơn để truy nhập đến tùy chọn socket IGMP Linux, hạn chế có ảnh hưởng tốt đến phiên dịch Giới hạn mặc định Linux phiên 2.6.18 2.6.31 20 nhóm Hơn nữa, số lượng thành viên nhóm, số lượng nguồn thu bị giới hạn 10 địa cho nhóm Số lượng kênh SSM bị giới hạn 10 kênh Số lượng mặc định không đủ cho phiên dịch multicast sử dụng nhiều host IPv6 Tuy nhiên số lượng điều chỉnh người quản trị Bởi yêu cầu phải hỗ trợ SSM lọc nguồn dùng cho SSM hỗ trợ IGMPv3 nên phiên dịch phải kết nối với router IPv4 lân cận IGMPv3 Nếu phiên cũ IGMP (IGMPv1, IGMPv2) tồn CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan 77 Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 Chương link tồn hệ thống IGMPv3 bao gồm phiên dịch phải trở lại phiên cũ để bảo tồn tính tương thích với mạng Việc trở lại phiên cũ ngăn cản việc lọc nguồn kênh SSM ngưng làm việc Với hạn chế nói trên, để phiên dịch hoạt động tốt nên kết nối phiên dịch với router IPv4 lân cận link chuyên dụng dành riêng cho phiên dịch Mặt khác, khắc phục hạn chế cách sử dụng PIM để kết nối với router IPv4 lân cận Việc sử dụng PIM khơng kích hoạt tính hỗ trợ IGMP router IPv4 lân cận Tuy nhiên so với PIM IGMP mang lại nhiều lợi ích cho phiên dịch Bởi IGMP giao thức đơn giản so với PIM, nhiều thiết bị hỗ trợ IGMP Hơn IGMP không cần quan tâm tới vị trí router hội tụ, điều đơn giản hóa cấu hình phiên dịch Việc sử dụng IGMP cịn làm giảm tượng ngập lụt gói multicast mạng IGMP có chế ngăn cản tràn lụt gói multicast 3.8 Vấn đề bảo mật Bởi phiên dịch không hỗ trợ phiên dịch phạm vi địa multicast, nên multicast IPv4 nội phiên dịch thành multicast IPv6 toàn cầu Việc cài đặt phiên dịch vào mạng PIM hành làm nhóm multicast khơng mong muốn kết nối thành công với host IPv6 Bộ phiên dịch khơng hỗ trợ tính loại bỏ nhóm multicast tất nhóm multicast IPv4 tự kết nối đến phiên dịch CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan 78 Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 Chương kết nối đến host IPv6 Nếu phiên dịch cấu hình tiền tố multicast tồn cầu nhóm dịch truy cập bên khu vực định tuyến multicast điều số tình khơng mong muốn Nếu muốn nhóm dịch có ý nghĩa khu vực định tuyến multicast nội phiên dịch phải cấu hình với tiền tồ multicast nội Ngoài việc lọc tin Join PIM phải thực đường biên AS router để phiên dịch kết nối xác Việc lọc tin Join PIM sử dụng để loại bỏ số nhóm khơng cho kết nối với phiên dịch ngăn cản phạm vi nhóm dịch đường biên AS Đóng vai trị router PIM mạng IPv6, phiên dịch chịu ảnh hưởng vấn đề bảo mật tương tự router PIM khác mạng IPv6 Ví dụ host IPv6 khơng mong muốn gửi tin Join Register đến phiên dịch làm cho gói tin khơng hợp lệ chuyển đến nhóm ASM dịch Vấn đề đặc biệt ảnh hưởng đến nhóm IPTV nhóm IPTV thường có nguồn hợp pháp Vấn đề giảm thiểu cách lọc bỏ gói tin PIM unicast gửi đến phiên dịch Việc lọc bỏ tin PIM unicast ngăn cản toàn việc tiếp nhận tin đăng ký Register PIM IPv6, đảm bảo tồn gói tin multicast chuyển tiếp từ phiên dịch đến từ nguồn IPv4 Đương nhiên biện pháp khơng thể bảo vệ nhóm IPTV dịch biện pháp tương tự không thực mạng IPv4 CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan 79 Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 3.9 Chương Kết luận Như kiến trúc phiên dịch thiết kế, phiên dịch thỏa mãn tất yêu cầu đặt chương Về yêu cầu chức năng, phiên dịch hỗ trợ tất giao thức truyền tải sử dụng SIIT Bộ phiên dịch có giao diện quản lý CLI MRD6 để giám sát dịch vụ, đồng thời có nhật ký thành phần nhật ký kiện MRD6 để ghi lại kiện Về yêu cầu hiệu suất: với điều kiện truyền dẫn tải phiên dịch khơng làm gói Bộ phiên dịch phiên dịch hàng chục kênh IPTV lúc với thời gian trễ nằm giới hạn 5ms thời gian gia nhập nhóm nằm giới hạn 500ms Tuy nhiên độ trễ gia nhập phụ thuộc vào số hop host gia nhập phiên dịch Vị trí phiên dịch phải tính tốn kỹ để đảm bảo trễ gia nhập không 500ms Bộ phiên dịch thực nhận gói tin đến, phiên dịch chuyển tiếp gói trước xử lý gói Như phiên dịch không làm xáo trộn thứ tự gói tin Bộ phiên dịch thực thuật toán phân mảnh router khác mạng IPV6, trì MTU đường dẫn cho địa đích IPv6 thực phân mảnh gói tin lớn MTU bất chấp cờ DF Việc gây trễ gia nhập cho host có MTU thấp MTU đường dẫn trước Bởi phiên dịch khơng hỗ trợ phiên dịch phạm vi địa nên việc đặt phiên dịch đâu cung cấp tiền tố cho phiên dịch cần phải tính tốn kỹ ảnh hưởng trực tiếp đến tính bảo mật thơng tin CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan 80 Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 Chương Cuối cùng, với thiết kế trình bày phiên dịch chạy tốt cấu hình máy tính bình thường với hệ điều hành Linux Như kiến trúc phiên đưa chương đáp ứng hoàn toàn yêu cầu đặt luận văn CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan 84 Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 PHỤ LỤC PHỤ LỤC A Giao diện quản lý đầu CLI MRD6 # show translator IPv4 to IPv6 multicast translator is enabled IPv4 interface: eth0 IPv4 address: 192.0.2.75 Unicast prefix: 2001:db8:ab:cd:ef::/96 ASM prefix: ff7e:140:2001:db8:ab:cd::/96 SSM prefix: ff3e::/96 Translated groups: # show group Group ff7e:140:2001:db8:ab:cd:ef54:6565 PIM Rendezvous-Point: 2001:db8:ab:cd::1 [embedded, self] Sources: (*) Uptime: 12m 6s Input Interface: eth0, Upstream: (Self) Output Interfaces: eth0, 3h 43m 7s, Forwarding (2001:db8:ab:cd:ef:0:c000:26d), SPT, Active, Uptime: 12m 6s Input Interface: VirtualIPv4, Upstream: (None) Immediate Output Interfaces: eth0, 3m 25s, Forwarding (2001:db8:ab:cd:ef:0:c000:26d, RPT) Uptime: 12m 6s Input Interface: eth0, Upstream: (Self) Local interest: Exclude # show counters Group ff7e:140:2001:db8:ab:cd:ef54:6565 (pim) CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan 85 Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 PHỤ LỤC Aggregate activity statistics: Current rate: 6.60 Mb/s (605.00 pkt/s) Last 60 secs: 49492985 bytes (36300 packets, 1363.44 bytes/packet) Sources: 2001:db8:ab:cd:ef:0:c000:26d Activity statistics: 6.60 Mb/s (604.52 pkt/s) Last 60 secs: 49492956 bytes (36271 packets, 1364.53 bytes/packet) CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan 86 Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 PHỤ LỤC PHỤ LỤC B Nhật ký đầu MRD6 [Sep 23 16:22:01:072666] [eth0] PIM, JOIN/PRUNE message from fe80::224:dcff:fe12:3456 to ff02::d len 114 [Sep 23 16:22:01:072712] [eth0] PIM, PIM J/P for fe80::215:c5ff:feab:cdef with holdtime 210000 [Sep 23 16:22:01:072829] ff7e:140:2001:db8:ab:cd:ef54:6565 [Sep 23 16:22:01:072910] Join: 2001:db8:ab:cd:ef:0:c000:26d [Sep 23 16:22:01:073003] ff7e:140:2001:db8:ab:cd:ef54:6565 [Sep 23 16:22:01:073049] Join: 2001:db8:ab:cd::1 RPT WC [Sep 23 16:22:01:073080] Created group ff7e:140:2001:db8:ab:cd:ef54:6565 using source discs data-plane [Sep 23 16:22:01:073126] Created Group ff7e:140:2001:db8:ab:cd:ef54:6565 [Sep 23 16:22:01:073193] Create state for group ff7e:140:2001:db8:ab:cd:ef54:6565 [Sep 23 16:22:01:073219] Translator: Joining IPv4 ASM group (*, 239.84.101.101) [Sep 23 16:22:01:076779] (ff7e:140:2001:db8:ab:cd:ef54:6565) PIM, Created state (*, G) [Sep 23 16:22:01:076816] (ff7e:140:2001:db8:ab:cd:ef54:6565) PIM, (*) set_oif eth0 13392000 join [Sep 23 16:22:01:076852] (ff7e:140:2001:db8:ab:cd:ef54:6565) PIM, (*) Added intf eth0 [Sep 23 16:22:01:076917] (ff7e:140:2001:db8:ab:cd:ef54:6565) PIM, (*) Intf(eth0) Updated with join for 3h 43m 12s [Sep 23 16:22:01:076968] (ff7e:140:2001:db8:ab:cd:ef54:6565) PIM, (*) Intf(eth0) changed J/P State NoInfo -> Joined [Sep 23 16:22:01:077012] CBHD: TS Trịnh Quang Khải (ff7e:140:2001:db8:ab:cd:ef54:6565) HVTH: Hoàng Thị Ngoan 87 Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 PHỤ LỤC PIM, (*) Intf(eth0) Changed state NoInfo -> Include [Sep 23 16:22:01:077045] Created source state for 2001:db8:ab:cd:ef:0:c000:26d [Sep 23 16:22:01:077135] (ff7e:140:2001:db8:ab:cd:ef54:6565) PIM, (2001:db8:ab:cd:ef:0:c000:26d) Internal activity changed to true CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan 88 Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 PHỤ LỤC PHỤ LỤC C Cấu hình MRD6 log { attach stderr normal; attach default "mrd.log" normal; } console { allow-access admin admin any; } interfaces { disable lo; disable eth1; disable eth2; disable sit0; } pim { disable bootstrap; } /* Cấu hình phiên dịch IPv4 – IPv6 */ translator { /* Giao tiếp IPv4 địa phiên dịch */ ipv4-interface = eth0; ipv4-address = 192.0.2.75; /* Tiền tố unicast đại diện cho địa nguồn IPv4 Tiền tố phải định tuyến đến phiên dịch mạng IPv6 */ unicast-prefix = 2001:db8:ab:cd:ef::/96; /* Tiền tố multicast đại diện cho địa nhóm ASM SSM IPv4 */ CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan 89 Nghiên cứu chế phiên dịch multicast IPv4 sang IPv6 PHỤ LỤC asm-prefix = ff7e:140:2001:db8:ab:cd::/96; ssm-prefix = ff3e::/96; } CBHD: TS Trịnh Quang Khải HVTH: Hoàng Thị Ngoan