TCVN11237-1:2015

Tiêu chuẩn quốc gia TCVN 11237-1:2015 về Giao thức cấu hình động Internet phiên bản 6 (DHCPv6) - Phần 1: Đặc tả giao thức TIÊU CHUẨN QUỐC GIA TCVN 11237-1:2015 GIAO THỨC CẤU HÌNH ĐỘNG INTERNET PHIÊN BẢN 6 (DHCPV6) - PHẦN 1: ĐẶC TẢ GIAO THỨC Dynamic host con f iguration protocol for IPv6 (DHCPv6) - Part 1: Protocol specification Lời nói đầu TCVN 11237-1:2015 được xây dựng trên cơ sở tài liệu I ETF RFC 3315:2003 (Dynamic Host Con f iguration Protocol for IPv6 - Giao thức cấu hình động cho internet phiên bản 6) của Nhóm đặc trách về kỹ thuật Internet (IETF). TCVN 11237-1:2015 do Vụ Khoa học v à Công nghệ 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ố. Bộ tiêu chuẩn TCVN 11237 Giao thức cấu hình động cho Internet phiên bản 6 (DHCPv6) gồm ba phần: - TCVN 11237-1:2015, Phần 1: Đặc tả giao th ứ c; - TCVN 11237-2:2015, Phần 2: Dịch vụ DHCP không giữ trạng thái cho IPv6; - TCVN 11237-3:2015, Phần 3: Các tùy chọn cấu hình DNS. GIAO THỨC CẤU HÌNH ĐỘNG CHO INTERNET PHIÊN BẢN 6 (DHCPV6) - PHẦN 1: ĐẶC TẢ GIAO THỨC Dynamic Host Con f iguration Protocol for I Pv6 (DHCPv6) - Part 1: Protocol speci f ication 1. Phạm vi áp dụng Tiêu chuẩn này mô tả giao thức cấu hình động cho Host sử dụng giao thức Internet phiên bản 6, cho phép các máy chủ DHCP chuyển các thông số cấu hình (như các địa chỉ IPv6) đến các nút mạng IPv6 để từ đ ó ấn định các địa chỉ mạng, tự động tái sử dụng và bổ sung cấu hình một cách linh động. Tiêu chuẩn này có thể được sử dụng đồng thời hoặc riêng rẽ với RFC 2462 để có được các tham số cấu hình. Tiêu chuẩn này cho phép sử dụng các biến định nghĩa bên trong tài liệu và các biến b ê n ngoài (khi người quản trị được phép thay đổi) đ ể mô tả giao thức. Tên các biến cụ thể, cách thức thay đổi giá trị và cách các thiết lập ảnh hưởng tới hành vi của giao thức được cung cấp để mô tả hành vi của giao thức. Việc triển khai không cần phải có các biến này ở dạng chính xác, chỉ cần các hành vi bên ngoài của nó phù hợp với những gì mô tả trong tiêu chuẩn này. 2. Tài liệu viện dẫn Tài liệu viện dẫn sau rất 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 phiên 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ả sửa đổi, bổ sung (nếu có). IETF RFC 768, User Datagram Protocol, 1980 (Giao thức Gói dữ kiện người dùng); IETF RFC 826, Ethernet Address Resolution Protocol,1982 (Giao thức phân tích địa chỉ Ethernet); IETF RFC 1305, Network Time Protocol (Version 3) Specification, Implementation, 1992 (Đặc điểm và thực thi giao thức thời gian mạng) ; IETF RFC 1321, The MD5 Message-Digest Algorithm, 1992 (Thuật toán MD5 Message-Digest) ; IETF RFC 2104, HMAC: Keyed-Hashing for Message Authentication, 1997 (Khóa Băm cho xác thực bản tin) ; IETF RFC 2119, Key w ords for use in RFCs to Indicate Requirement Levels, 1997 (Các từ khóa để sử dụng trong RFC nhằm chỉ báo Mức độ yêu cầu) ; IETF RFC 2131, Dynamic Host Con f iguration Protocol, 1997 (Giao thức c ấ u hình động cho Internet phiên bản 4); IETF RFC 2132, DHCP Options and BOOTP Vendor Extensions, 1997 (Các Tùy chọn DHCP và mở rộng nhà cung cấp BOOTP ); IETF RFC 2434, Guide l ines for W riting an IA_NA Considerations Section in RFCs, 1998 (Hướng dẫn viết một Mục xem xét IA_NA trong RFC); IETF RFC 2461, Neighbor Discovery for IP Version 6 (IPv6), 1998 (Khám phá Nút lân cận cho IPv6) ; IETF RFC 2462, IPv6 Stateless Address Autocon f iguration, 1998 (Tự động cấu hình địa chỉ không giữ trạng thái IPv6) ; IETF RFC 2464, Transmission of IPv6 Packets over Ethernet Networks, 1998 (Truyền gói tin IPv6 qua mạng Ethernet) ; IETF RFC 3041, Privacy Extensions for Stateless Address Autoconfiguration in IPv6, 2001 (Các m ở rộng bảo mật cho Tự động cấu hình địa chỉ không giữ trạng thái của IPv6); IETF RFC 3646, DNS Configuration options for DHCPv6, 2003 (Các tùy chọn cấu hình DNS cho DHCPv6) ; IETF RFC 4075, Time Con f iguration Options for DHCPv6, 2005 (Tùy chọn cấu hình thời gian cho DHCP phiên bản 6) ; IETF RFC 4301, Security Architecture for the Internet Protocol, 2005 (Kiến trúc bảo mật cho giao thức Internet). 3. Thuật ngữ và định nghĩa Tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa sau: 3.1 . Bản tin (Message) Đơn v ị dữ liệu được mang theo như một phần tải (payload) của một gói dữ liệu UDP, được trao đổi giữa các máy chủ DHCP, các nút mạng trung gian và các máy khách. 3.2 . Bộ định tuyến (Router) Nút mạng có khả năng chuyển tiếp các gói tin IPv6 mà không được định địa chỉ cho nút mạng đó. 3.3 . Định danh tầng liên kết (Link-layer identi f ier) Định danh tầng liên kết cho một giao diện. Các ví dụ bao gồm các địa chỉ IEEE 802 cho mạng Ethernet hoặc các giao diện mạng Token Ring và các địa chỉ E.164 cho các liên kết ISDN. 3.4 . Binding (Gắn kết) Một binding (hoặc binding máy khách) là một nhóm các bản ghi dữ liệu máy chủ, chứa thông tin máy chủ có được về các địa chỉ trong một IA hoặc thông tin cấu hình được ấn định cho máy khách. Thông tin cấu hình được trả về cho máy khách thông qua một nguyên tắc - ví dụ như thông tin phản hồi từ tất cả các máy khách trong cùng một liên kết) thì không yêu cầu binding. Một binding có chứa thông tin về IA được chỉ ra bởi bộ thông tin I A-type, IAID> (trong đó I A-type là kiểu của địa chỉ trong IA, chẳng hạn như kiểu temporary - tạm thời). Một binding chứa thông tin cấu hình cho máy khách được chỉ ra b ở i 3.5 . Chuyển tiếp (Relaying) Nút mạng trung gian DHCP chuyển tiếp các bản tin giữa các thành phần tham gia của DHCP. 3.6 . DUID - Định danh đ ơn DHCP (DHCP Unique IDenti f ier) Định danh duy nhất cho một thành phần tham gia DHCP; mỗi máy khách và máy chủ DHCP có một DUID xác định. Điều 9 thể hiện chi ti ế t cách thức tạo DUID. 3.7 . Độ dài ti ề n tố (Pre f ix length) Số bit trong tiền t ố. 3.8 . Địa chỉ (Address) Phần định danh tầng IPv6 cho một giao diện hoặc một tập hợp các giao diện. 3.9 . Địa chỉ liên kết cục bộ (Link-local address) Địa chỉ IPv6 có phạm vi liên kết được chỉ ra bởi tiền tố (FE80::/10), địa chỉ này được sử dụng để liên hệ đến các nút lân cận trong cùng liên kết. Mọi giao diện đều có một địa chỉ liên kết cục bộ. 3.10 . Địa chỉ Multicast (Multicast address) Địa chỉ Multicast dùng để xác định nhiều giao diện. Gói tin có đích đến là địa chỉ Multicast sẽ được chuyển đến tất cả các giao diện có cùng địa chỉ Multicast. 3.11 . Địa chỉ Unicast (Unicast address) Địa chỉ Unicast dùng đ ể xác định một giao diện (Inter f ace). Gói tin có đích đến là địa chỉ Unicast sẽ được chuyển đến một giao diện duy nhất. 3.12 . Giao diện (Inter f ace) Mặt tiếp giáp của nút mạng và liên kết. 3.13 . Giao thức cấu hình động cho Internet phiên bản 6 (Dynamic Host Configuration Protocol for IPv6 - DHCPV6) Các khái niệm DHCPv4 và DHCPv6 chỉ được sử dụng khi cần thiết để tránh sự hiểu lầm giữa hai giao thức. Trong tiêu chuẩn này, DHCP được hiểu là DHCPv6. 3.14 . Gói tin (Packet) Phần mào đầu IPv6 cộng với phần tải (payload). 3.15 . IP (Internet Protocol) Giao thức internet. 3.16 . IA - Tập định danh (Identity association) Tập hợp các địa chỉ được ấn định cho một máy khách. Mỗi IA đi kèm với một IAID. Một máy khách có thể có nhiều hơn một IA được ấn định cho n ó (ví dụ ấn định một IA cho từng giao diện của một máy khách). Mỗi I A giữ một kiểu của địa chỉ, ví dụ IA cho các địa chỉ tạm thời (IA_TA) giữ các địa chỉ tạm thời (xem thêm “IA cho các địa chỉ tạm thời”). Trong tiêu chuẩn này, “IA” được sử dụng để nói đến một tập hợp định danh mà không xác định kiểu của các địa chỉ trong IA. 3.17 . IAID - Định danh IA (Identity association identi f ier) Định danh cho một IA và được máy khách lựa chọn. Máy khách phải lựa chọn IAID sao cho mỗi IA có một IAID duy nhất trong tất cả các IAID của các IA thuộc về máy khách đó. 3.18 . IA_NA - IA cho c á c địa chỉ lâu dài (Identity association for non-temporary addresses) IA mang các địa chỉ lâu dài đã được ấn định. 3.19 . Khóa cấu hình lại (Recon f igure key) Khóa được máy chủ cung cấp cho máy khách để bảo mật cho bản tin Recon fi gure. 3.20 . Liên kết (Link) Thiết bị hay môi trường truyền thông mà trên đó các n ú t mạng có thể kết nối với nhau tại tầng liên kết, tức là tầng ngay bên dưới IPv6. Ví dụ như mạng Ethernet (kết nối đơn hay kết nối cầu), các liên kết PPP. 3.21 . Máy khách DHCP (DHCP Client) Nút mạng khởi tạo các yêu cầu trên một liên kết để lấy các thông số cấu hình từ một hoặc nhiều máy chủ DHCP. 3.22 . Miền DHCP (DHCP domain) Tập hợp các liên kết được DHCP quản lý và được vận hành bởi một đối tượng quản trị đơn lẻ. 3.23 . Máy chủ DHCP (DHCP server) Nút mạng (có thể cùng hoặc không cùng một liên kết với các máy khách) phản hồi lại các yêu cầu của các máy khách. 3. 24 . Host Bất kỳ nút mạng nào mà không phải là Bộ định tuyến. 3.25 . Nút mạng trung gian DHCP (DHCP relay agent) Nút mạng đóng vai trò trung gian để chuyển các bản tin DHCP giữa các máy khách và các máy chủ trên cùng một liên kết với máy khách. 3.26 . Nút lân cận (Neighbor) Các nút mạng gắn với cùng một liên kết. 3.27 . Nút mạng (Node) Thiết bị thực thi IPv6. 3.28 . Phù hợp với liên k ế t (Appropriate to the link) Một địa chỉ được gọi là “Phù hợp với liên kết” khi địa chỉ phù hợp với thông tin của máy chủ DHCP về kiến trúc mạng, sự ấn định tiền tố và các chính sách ấn định. 3.29 . IA cho các địa chỉ tạm thời (Identity association for temporary addresses) Một IA mà mang các địa chỉ tạm thời (xem RFC 3041). 3.30 . Thông số cấu hình (Configuration parameter) Một phần tử của thông tin cấu hình, được thiết lập trên máy chủ và chuyển đến máy khách bằng cách s ử d ụng DHCP. Ví dụ , một nút mạng có thể sử dụng các th ô ng số cấu hình (có mang thông tin) để cấu hình mạng con của chính nó và giao tiếp có thể sử dụng được trên cùng một liên kết hoặc liên mạng. 3.31 . Tiền tố (Prefix) Các bit đầu của một địa chỉ hoặc một tập các địa chỉ có chung các bit đầu. 3.32 . Transaction ID (ID chuyển giao) Giá trị không xác định được sử dụng để phản hồi tương ứng với các bản tin Reply được khởi tạo bởi máy chủ hoặc máy khách. 3.33 . UDP (User Datagram Protocol) Giao thức gói dữ liệu (datagr a m) người dùng. Đây là giao thức cốt lõi của giao thức TCP/IP, được sử dụng để gửi những dữ liệu ngắn được gọi là datagram từ máy này tới máy khác. 3.34 . Vùng DHCP (DHCP realm) Tên được sử dụng để định danh miền quản trị DHCP từ đó lựa chọn khóa xác thực DHCP. 4. Tổng quan Tiêu chuẩn này mô tả giao thức cấu hình động cho host sử dụng giao thức IPv6 - một giao thức chủ/khách (client/server) nhằm cung cấp cấu hình cho các thiết bị. DHCP cung cấp cho thiết bị các địa chỉ (đã được ấ n định bởi một máy chủ DHCP) và thông tin cấu hình khác (được mang trong các tùy chọn). DHCP được mở rộng thông qua các tùy chọn m ớ i mang thông tin cấu hình không được quy định trong tiêu chuẩn này. DHCP là “giao thức tự động cấu hình địa chỉ có giữ trạng thái (stateful)” và “giao thức tự động cấu hình có giữ trạng thái” được nói đến trong tài liệu “Cấu hình địa chỉ tự động không giữ trạng thái trong IPv6”. Các mô hình hoạt động và thông tin cấu hình có liên quan đến DHCPv4 khác với DHCPv6 và việc kết hợp giữa hai dịch vụ này không được đề cập trong tiêu chuẩn này. Việc kết hợp này được quy định trong tài liệu mở rộng DHCPv6 để nó có thể bao gồm các địa chỉ IPv4 và thông tin cấu hình. Tiêu chuẩn này tóm tắt về DHCP, giải thích các cơ chế trao đổi bản tin và ví dụ về các luồng tin. Các luồng tin trong 4.2 và 4.3 là để minh họa của hoạt động DHCP chứ không phải là tất cả các tương tác có thể có giữa máy chủ-máy khách. Các Điều 17, 18 và 19 giải thích chi tiết hoạt động của máy chủ và máy khách. 4.1. Các giao thức và định địa chỉ Các máy chủ và máy khách trao đổi bản tin DHCP bằng cách sử dụng giao thức UDP. Theo đó, máy khách sử dụng một địa chỉ liên kết cục bộ (hoặc các địa chỉ được xác định thông qua các cơ chế khác) để truyền và nhận các bản tin DHCP. Các máy chủ DHCP sử dụng một địa chỉ multicast dành riêng (đã xác định trong liên kết) để nhận bản tin từ các máy khách. Máy khách DHCP truyền phần lớn bản tin tới địa chỉ multicast đã dành riêng này, do đó máy khách không được cấu hình với địa chỉ này hoặc các địa chỉ của các máy chủ DHCP. Để máy khách DHCP có thể gửi bản tin tới máy chủ DHCP không cùng một liên kết, DHCP sử dụng nút mạng trung gian DHCP (trong liên kết của máy khách) để chuyển tiếp các bản tin giữa máy chủ và máy khách. Hoạt động của nút mạng trung gian là trong suốt đ ố i với máy khách (máy khách không bi ế t) do đó các quá trình trao đổi bản tin được mô tả sau đây s ẽ không đề cập đến quá trình trung chuyển bản tin bởi các nút mạng trung gian. Trong một số trường hợp, khi máy khách đã xác định được địa chỉ của máy chủ, nó có thể sử dụng phương thức unicast để gửi bản tin trực tiếp tới máy chủ. 4.2. Trao đổi máy chủ - khách liên quan tới hai bản tin Khi một máy khách DHCP không cần gán địa chỉ IP từ máy chủ DHCP, máy khách có thể lấy thông tin cấu hình (chẳng hạn là một d anh sách các máy chủ DNS có sẵn hoặc các má y chủ NTP) thông qua một bản tin đơn và trao đổi trả lời với máy chủ DHCP. Để có được thông tin cấu hình, trước tiên máy khách gửi một bản tin In f ormation-Request tới địa chỉ multicast AII_DHCP_Relay_Agents_and_Servers. Máy chủ gửi trả lại một bản tin Reply có chứa thông tin cấu hình cho máy khách. Việc trao đổi bản tin n à y được giả định trong trường hợp máy khách ch ỉ yêu cầu thông tin cấu hình mà không yêu cầu ấn định bất kỳ địa chỉ IPv6 nào. Khi một máy chủ có các địa chỉ IPv6 và thông tin cấu hình khác đã dành sẵn cho máy khách, máy khách và máy chủ có thể hoàn tất quá trình trao đ ổ i chỉ với 2 bản tin thay vì bốn bản tin như mô tả trong phần sau. Trong trường hợp này, máy khách gửi bản tin Solicit tới AII_DHCP Relay_A g ents_and_Servers yêu cầu ấn định các địa chỉ và thông tin cấu hình khác. Bản tin này bao g ồ m một d ấ u hiệu cho thấy máy khách sẵn sàng nhận bản tin Reply tức thời từ máy chủ. Máy chủ này sẵn sàng để ấn định địa chỉ tức thời cho máy khách phản hồi lại bản tin Reply. Thông tin c ấ u h ì nh và địa chỉ trong bản tin Reply là sẵn sàng để máy khách sử dụng. Mỗi địa chỉ được ấn định cho máy khách có thời gian tồn tại hiệu lực do máy chủ quy định. Để yêu cầu tăng thời gian tồn tại đã được ấn định cho địa chỉ này, máy khách gửi bản tin Rene w tới máy chủ. Máy chủ gửi bản tin Reply tới máy khách kèm theo thời gian tồn tại mới, cho phép máy khách tiếp tục sử dụng địa chỉ này mà không bị gián đoạn. 4.3. Trao đổi ch ủ - khách liên quan đến b ố n bản tin Để yêu cầu ấn định một hoặc nhiều địa chỉ IPv6, máy khách trước tiên phải xác định được vị trí máy chủ DHCP, sau đó yêu cầu ấn định các địa chỉ và thông tin cấu hình khác từ máy chủ. Máy khách gửi bản tin Solicit tới địa chỉ AII_DHCP _ Relay _ Agents_and_Servers để tìm kiếm các máy chủ DHCP sẵn sàng. Máy chủ nào th ỏ a mãn được yêu cầu c ủ a máy khách thì phản hồi lại bằng bản tin Advertise. Máy khách s a u đ ó chọn một trong các máy chủ và gửi bản tin Request tới máy chủ yêu cầu ấn định địa chỉ chắc chắn và thông tin cấu hình khác. Máy chủ phản hồi bằng bản tin Reply có chứa địa chỉ chắ c chắn và cấu hình. Như đ ã mô tả ở trên, máy khách gửi bản tin Renew tới máy chủ đ ể tăng thời gian tồn tại của các địa chỉ đã được ấn định cho máy khách để máy khách tiếp tục sử dụng các địa chỉ này mà không bị gián đoạn. 5. Các hằng số DHCP Phần này mô tả về chương trình và các hằng số mạng được DHCP sử dụng. 5.1. Các địa chỉ Multicast DHCP sử dụng các địa chỉ multicast sau đây: AII_DHCP_Relay _ Agents_and_Servers (FF02::1:2): Địa chỉ multicast có kết nối đã xác định phạm vi được máy khách dùng để giao tiếp với các nút mạng trung gian lân cận và các máy chủ lân cận (trong liên kết). Tất cả các máy chủ và nút mạng trung gian là các thành viên của nhóm multicast này. AII_DHCP_Servers (FF05::1:3): Địa chỉ multicast có vùng hoạt động đã xác định phạm vi được nút mạng trung gian sử dụng để giao tiếp với các máy chủ khi nút mạng trung gian muốn gửi bản tin tới tất cả các máy chủ hoặc khi nó không biết các địa chỉ unicast của các máy chủ. Lưu ý r ằ ng để nút mạng trung gian sử dụng địa chỉ này, nó phải có một địa chỉ có phạm vi đủ để các máy chủ có thể truy cập. Tất cả các máy chủ trong vùng hoạt động l à các thành viên của nh ó m multicast này. 5.2. Các cổng UDP Máy khách lắng nghe các bản tin DHCP tại cổng UDP 546. Các máy chủ và các nút mạng trung gian lắng nghe các bản tin DHCP tại cổng UDP 547. 5.3. Các kiểu bản tin DHCP DHCP định nghĩa các kiểu bản tin như liệt kê đây. Các kiểu bản tin n à y được mô tả chi tiết hơn tại Điều 6. và 7. Các kiểu bản tin không liệt kê ra ở đây dành để sử dụng trong tương lai. Mã số cho mỗi kiểu bản tin được chỉ ra trong phần ngoặc (). SOLICIT (1) Máy khách gửi bản tin Solicit để định vị các máy chủ. ADVERTISE (2) Máy chủ gửi bản tin Advertise để chỉ ra rằng nó sẵn sàng cho dịch vụ DHCP, đáp ứng với bản tin Solicit đã nhận được từ máy khách. REQUEST (3) Máy khách gửi bản tin Request để yêu cầu các thông số cấu hình, bao g ồ m các địa chỉ IP từ một máy chủ cụ th ể . CONFIRM (4) Máy khách gửi bản tin Con f irm tới máy chủ khả d ụng bất kỳ đ ể xác định liệu các địa chỉ đã được ấn định có còn thích hợp với kết n ố i tới máy khách đã được kết nối tới. RENEW (5) Máy khách gửi bản tin Renew tới máy chủ (đã cung cấp địa chỉ IP và thông số cầu hình cho máy khách này) để tăng thời gian tồn tại của các địa chỉ đ ã được ấn định và để cập nhật các thông số cầu hình khác. REBIND (6) Máy khách gửi bản tin Rebind tới máy chủ kh ả dụng bất kỳ để tăng thời gian tồn tại của các địa chỉ đã được ấn định và để cập nhật các thông số cấu hình khác; bản tin n à y được gửi đi sau khi máy khách không nhận được phản hồi đ ố i với bản tin Renew. REPLY (7) Máy chủ gửi bản tin Reply chứa các địa chỉ đã được ấn định và các thông số cấu hình để phản hồi bản tin Solicit, Request, Renew, Rebind nhận được từ máy khách. Máy chủ gửi bản tin Reply chứa các thông số cấu hình đ ể đáp ứng với bản tin Information-request. Máy chủ gửi bản tin Reply để đáp ứng với bản tin Con f irm để khẳng định hoặc từ ch ố i các địa chỉ đã được ấn định cho máy khách l à phù hợp với liên kết mà máy khách được n ố i tới. Máy chủ gửi bản tin Reply để xác nhận đã nhận được b ả n tin Release hay Decline. RELEASE (8) Máy khách gửi bản tin R e lease tới máy chủ đã ấn định địa chỉ cho nó đ ể thông báo rằng máy khách sẽ không sử dụng một hoặc nhiều địa chỉ đã ấn định. DECLINE (9) Máy khách gửi bản tin Decline tới máy chủ để thông báo rằng máy khách đã xác định một (hoặc nhiều) địa chỉ (đã được ấn định bởi máy chủ) đã được sử dụng xong cho liên kết mà máy khách đã kết n ố i tới. RECONFIGURE (10) Máy chủ gửi bản tin Recon f igure tới máy khách để thông báo cho máy khách rằng máy chủ có các thông tin cấu hình mới hoặc đ ã được cập nhật và máy khách cần khởi tạo giao dịch Renew/Reply hay Information-request/Reply với máy chủ để nhận thông tin đã cập nhật. INFORMATION- REQUEST (11) Máy khách gửi bản tin In f ormation-request tới máy chủ để yêu cầu các thông số cấu hình mà không cần ấn định bất kỳ địa chỉ IP nào cho máy khách. RELAY-FORW(12) Nút mạng trung gian gửi bản tin Relay-forward để chuyển tiếp các bản tin tới c á c máy chủ, có thể chuyển trực tiếp hoặc thông qua nút mạng trung gian khác. Bản tin nhận được (có thể là bản tin máy khách hoặc bản tin Relay- forward từ nút mạng trung gian khác) được đóng gói trong tùy chọn nằm trong bản tin ReIay-forward. RELAY-REP L (13) Máy chủ gửi bản tin Relay-reply tới nút mạng trung gian chứa bản tin mà nút mạn g trung gian chuyển tới máy khách. Bản tin Relay-reply có th ể đã được chuy ể n tiếp qua các nút mạng trung gian khác để tới nút mạng tr u ng gian đích. Máy chủ đóng gói bản tin máy khách như một tùy chọn trong bản tin Relay-rep l y mà bản tin này được nút mạng trung gian trích ra và chuyển tiếp tới máy khách. 5.4. Các mã trạng thái DHCPv6 sử dụng các mã trạng thái để thông tin về sự thành công hay thất bại của các hoạt động được yêu cầu trong các bản tin từ m á y khách, máy chủ và để cung cấp thông tin bổ sung về nguyên nhân thất bại cụ thể của một bản tin. Các mã trạng thái cụ thể được mô tả trong Điều 24.4. 5.5. Các thông số truyền và truy ề n lại Sau đây là bảng các giá trị được sử dụng để mô t ả về hành vi truyền bản tin của máy khách và máy chủ. Thông số Giá trị mặc định Mô tả SOL _ MAX _ DELAY 1 giây Độ trễ tối đa của bản tin Solicit đầu tiên SOL _ TIM EO UT 1 giây Thời gian chờ khởi tạo bản tin Solicit SOL _ MAX _ RT 120 giây Thời gian chờ tối đa bản tin Solicit REQ _ TIMEOUT 1 giây Thời gian khởi tạo bản tin Request REQ _ MAX _ RT 30 giây Thời gia n chờ tối đa bản tin Request REQ _ MAX _ RC 10 Số lần thử lại tối đa của bản tin Request CNF _ MAX _ DELAY 1 giây Độ trễ tối đa của bản tin Confirm đầu tiên CNF _ TIM EO UT 1 giây Thời gian chờ khởi tạo bản tin Confirm CNF _ MAX _ RT 4 giây Thời gian chờ tối đa bản tin Confirm CNF _ MAX _ RD 10 giây Thời gian tối đa cho quá tr ì nh Confirm REN _ TIMEOUT 10 giây Thời gian chờ khởi tạo bản tin Renew REN _ MAX _ RT 600 giây Thời gian chờ tối đa bản tin Renew REB _ TIMEOUT 10 giây Thời gian chờ khởi tạo bản tin Rebind REB _ MAX _ RT 600 giây Thời gian chờ tối đa bản tin Rebind INF_MAX_DELAY 1 giây Trễ t ố i đa của bản tin Information-request đầu tiên INF_TIMEOUT 1 giây Thời gian chờ khởi tạo bản tin Information- request INF _ MAX _ RT 120 giây Thời gian chờ tối đa bản tin Information-request REL _ TIMEOUT 1 giây Thời gian chờ khởi tạo bản tin Release REL _ MAX _ RC 5 Số lần th ử lại tối đa bản tin Release DEC _ TIMEOUT 1 giây Thời gian chờ khởi tạo bản tin Decline DEC _ MAX _ RC 5 Số lần thử lại bản tin Decline tối đa REC _ TIM EO UT 2 giây Thời gian chờ khởi tạo bản tin Reconfigure REC _ MAX _ RC 8 Số lần thử lại Reconfigure tối đa HOP _ COUNT _ LIMIT 32 Số bước đếm tối đa trong một bản tin Relay- forward 5.6 . Biểu diễn giá trị thời gian và giá trị “vô hạn” của thời gian Tất cả các giá trị thời gian cho thời gian tồn tại (T1 và T2) là các số nguyên không dấu. Giá trị 0 xffffffff được hiểu là “vô hạn” khi được sử dụng làm thời gian tồn tại (như trong RFC 2461) hay làm giá trị cho T1 hoặc T2. 6. Các định dạng bản tin chủ/khách Tất cả các bản tin DHCP được gửi giữa máy khách và máy chủ đều có phần mào đầu c ố định đồng nhất và một vùng định dạng biến đổi cho các tùy chọn. Tất cả các giá trị trong phần mào đầu bản tin và trong các tùy chọn ở thứ tự Byte mạng. Các tùy chọn được lưu trữ tuần tự trong trường Options, không có phần đệm giữa các tùy chọn. Các tùy chọn tính theo byte nhưng không được sắp theo thứ tự như các đường bao 2 hoặc 4 byte. Hình vẽ dưới đây mô tả định dạng của các bản tin DHCP được gửi giữa máy chủ và máy khách: msg-type Xác định kiểu bản tin DHCP; các kiểu bản tin khả dụng được liệt kê trong Điều 5.3. transaction-id Transaction ID của quá trình trao đổi bản tin này. options Các tùy chọn được mang trong bản tin này; các tùy chọn được mô tả trong Điều 22. 7. Định dạng bản tin Nút mạng trung gian/máy chủ Các nút mạng trung gian trao đổi bản tin với m á y ch ủ để chuyển tiếp các bản tin giữa máy khách và máy chủ mà chúng không được kết nối trong cùng một liên kết. Tất cả các giá trị trong mào đầu bản tin và trong các tùy chọn đều ở dạng thứ tự byte mạng. Các tùy chọn được lưu trữ tuần tự trong trường Options, không có phần đệm giữa các tùy chọn. Các tùy chọn tính theo byte nhưng không được sắp theo thứ tự như các đường bao 2 hoặc 4 byte. Có 02 bản tin nút mạng trung gian và có chung định dạng như sau: Phần tiếp theo mô tả cách sử dụng phần mào đầu của bản tin Nút mạng trung gian. 7.1 . Bản tin Re l ay-forward B ả ng sau đây quy định v i ệc sử dụng các trường trong bản tin Relay-forward. msg-type RELAY-FORW hop-count Số nút mạng trung gian đã trung chuyển bản tin. l ink-address Các địa chỉ toàn cục hoặc nội bộ vùng được máy chủ sử dụng để xác định liên kết mà máy khách được định vị trên đó. peer-address Địa chỉ của máy khách hoặc nút mạng trung gian mà từ đó bản tin được nhận để trung chuyển ti ế p. options PHẢI bao gồm “tùy chọn bản tin Relay” (xem 22.10); CÓ TH Ể bao gồm các tùy chọn khác được thêm bởi nút mạng trung gian. 7.2. Bản tin Relay-reply Bảng sau đây quy định v i ệc sử dụng các trường trong bản tin Relay-reply. msg-type RELAY-REPL hop-count Sao chép từ bản tin Relay-forward link-address Sao chép từ bản tin Relay-forward peer-address Sao chép từ bản tin Relay-forward options PHẢI bao gồm “tùy chọn bản tin Relay” (xem 22.10); CÓ TH Ể bao gồm các tùy chọn khác. 8. Biểu diễn và sử dụng các tên miền Các tên miền có thể được mã hóa cùng kiểu và tên miền hay danh sách tên miền được mã bằng cách sử dụng các kỹ thuật như mô tả trong Điều 3.1 của RFC 1035. T ê n miền hay danh sách tên miền trong DHCP KHÔNG ĐƯỢC phép lưu trữ ở dạng nén như quy định trong 4.1.4 của RFC 1035. 9. Định danh đơn DHCP Mỗi máy khách và máy chủ DHCP có một DUID. Các máy chủ DHCP sử dụng các DUID để định danh các máy khách để lựa chọn các thông số cấu hình và để kết hợp với các IA với máy khách. Các máy khách DHCP sử dụng các DUID để định danh máy chủ trong các bản tin mà máy chủ cần được định danh. Xem thêm Điều 22.2 và 22.3 về cách biểu diễn DUID trong bản tin DHCP. Máy khách v à máy chủ PHẢI xem các DUID như các giá trị không trong suốt và PHẢI so sánh các DUID công bằng. Máy khách và máy chủ KHÔNG ĐƯỢC theo cách bất kỳ để biên dịch các DUID. Máy khách và máy chủ KHÔNG ĐƯỢC hạn chế các DUID đối với các ki ể u được định nghĩa trong tiêu chuẩn này, cũng như các kiểu DUID bổ sung có thể được định nghĩa trong tương lai. DUID được mang trong một tùy chọn bởi v ì nó có thể có độ dài thay đổi được và bởi vì nó không bị yêu cầu trong tất cả các bản tin DHCP. DUID được tính toán l à du y nhất trong tất cả các máy khách và máy chủ DHCP và ổn định đối với một máy chủ hay máy khách bất kỳ - như vậy, DUID được dùng bởi một m á y khách hoặc máy chủ sẽ KHÔNG NÊN thay đổi trong suốt thời gian nếu có thể; ví dụ, DUID của một thiết bị không nên bị thay đổi bởi vì nó sẽ dẫn đến thay đổi phần cứng mạng của thiết bị. Động lực để có nhiều kiểu DUID là DUID PHẢI là duy nhất toàn cục và nó PHẢI dễ tạo ra. Nhóm định danh d uy nhất toàn cục mà dễ tạo ra với 1 thiết bị cụ thể bất kỳ thì có thể khác xa. Đồng thời, một số thiết bị có thể không chứa bộ phận lưu trữ liên tục. Việc giữ lại một DUID đã tạo ra trong thiết bị kiểu này là không thể và mô hình DUID PHẢI phù hợp với các thiết bị này. 9.1. Nội dung DUID DUID chứa một đoạn mã kiểu 2-octet được biểu diễn dưới dạng thứ tự byte mạng, kèm theo một số octet để tạo nên 1 định danh thực. DUID có thể dài không quá 128 octet (không bao gồm mã kiểu). Các kiểu đã được định nghĩa bao gồm: - Địa chỉ tầng liên kết cộng thời gian - ID duy nhất do nhà cung cấp ấn định dựa trên mã doanh nghiệp (Enterprise Number) - Địa chỉ tầng liên kết Các định dạng dành cho trường thay đ ổ i của DUID ứng với mỗi kiểu nói trên được thể hiện dưới đây. 9.2. DUID dựa trên địa chỉ t ầ ng liên kết cộng thời gian Kiểu DUID này bao gồm một trường ki ể u 2-octet chứa giá trị 1, 1 mã kiểu phần cứng 2-octet, 4 octet chứa giá trị thời gian, kèm theo địa chỉ tầng liên kết của một giao diện mạng bất kỳ được nối với thiết bị DHCP ở thời điểm mà DUID được tạo ra. Giá trị thời gian là thời gian mà DUID được tạo ra t í nh bằng giây từ thời điểm giữa đêm (UTC) ngày 1/1/2000, giá trị modulo 2 ^ 32. Kiểu phần cứng PHẢI là kiểu ph ầ n cứng phù hợp được ấn định bởi IA_NA như được mô tả trong RFC 826. C ả giá trị thời gian và kiểu phần cứng được lưu trữ ở thứ tự byte mạng. Địa chỉ tầng liên kết được lưu trữ ở dạng chuẩn như mô tả trong RFC 2464. Hình vẽ sau đây mô tả định dạng của DUID-LLT: Việc lựa chọn giao diện mạng có thể được hoàn thành khi mà giao diện này cung cấp một địa chỉ tầng liên kết duy nhất toàn cục cho kiểu liên kết và DUID-LLT tương tự N Ê N được sử dụng để cấu hình tất cả các giao diện mạng nối với thiết bị bất kể việc địa chỉ tầng liên kết của giao diện này có được sử dụng để tạo ra DUID-LLT hay không. Máy khách và máy chủ sử dụng DUID này PHẢI lưu trữ DUID-LLT trong bộ nhớ ổ n định và PHẢI tiếp tục sử dụng DUID-LLT này ngay cả khi giao diện mạng được sử dụng để tạo ra DUID-LLT này đã b ị ngắt ra. Máy khách và máy chủ không có bộ lưu trữ ổn định KHÔNG ĐƯỢC sử dụng kiểu DUID này. Máy khách và máy chủ sử dụng DUID này NÊN thử lại việc cấu hình trước khi tạo ra DUID, nếu có thể và PH Ả I sử dụng một số nguồn thời gian (v í dụ, đồng hồ thời gian thực) để tạo ra DUID ngay cả khi nguồn thời gian này chưa thể được cấu hình trước khi tạo ra DUID. Việc sử dụng nguồn thời gian có thể làm phát sinh ra 2 DUID-LLT giống nhau nếu giao diện mạng đã bị ngắt khỏi máy khách và một máy khách khác sử dụng cùng giao diện mạng này để tạo ra DUID-LLT. Sự xung đột giữa 2 DUID-LLT có thể dễ xảy ra hơn khi đồng hồ chưa được cấu hình trước khi tạo ra các DUID. Phương thức tạo DUID này được khuyến nghị đối với tất cả các thiết bị t í nh toán đa mục đích như máy tính để bàn và máy tính xách tay, cũng như các thiết bị máy in, bộ định tuyến... có chứa một số dạng thiết bị lưu trữ không ổn định. Dù đã cố gắng, nhưng có thể thuật toán để tạo ra DUID này có thể dẫn đến sự xung đột định danh máy khách. Máy khách DHCP tạo ra DUID-LLT sử dụng cơ ch ế này PHẢI tạo ra một giao diện quản lý để thay thế DUID hiện tại bằng DUID-LLT mới được tạo ra. 9.3. DUID đư ợ c ấn định bởi nhà cung cấp (thiết b ị ) dựa trên mã số nhà sản xuất Dạng DUID này được ấn định b ở i nhà cung cấp cho thiết bị. Nó bao gồm số đơn vị riêng đã được đăng ký của nhà cung cấp được duy trì bởi IA_NA kèm theo một định danh duy nhất được ấn định bởi nhà cung c ấ p. Hình vẽ sau đây tóm tắt cấu trúc của một DUID-EN: Nguồn định danh do nhà cung cấp định nghĩa, nhưng môi phần định danh của DUID-EN PHẢI là duy nhất đối với thiết bị sử dụng nó và PHẢI được ấn định cho thiết bị tại thời điểm nó được sản xuất và lưu trữ ở một dạng bộ nhớ không ổn định. DUID được tạo ra NÊN được lưu trữ trong bộ nhớ không thể bị xóa. Giá trị enterprise-number l à số đơn vị riêng đã được đăng ký của nhà cung cấp được duy trì bởi IA_NA. Giá trị enterprise-number được lưu như một số 32 bit không dấu. Ví dụ về loại DUID này như sau: Ví dụ này bao gồm 2-octet kiểu 2, số đơn v ị (9), theo đó là 8 octet dữ liệu định danh ( 0x0 CC084D303000912). 9.4. DUID dựa trên địa chỉ t ầ ng liên kết Kiểu DUID này bao gồm 2 octet chứa DUID kiểu 3, một mã kiểu phần cứng mạng 2-odet, kèm theo là địa chỉ tầng liên kết của một giao diện mạng bất kỳ được nối cố định tới máy khách hoặc máy chủ. Ví dụ, một host có giao diện mạng được thiết kế trong 1 chip để có thể tháo ra và sử dụng ở chỗ khác thì có thể sử dụng DUID-LL. Kiểu phần cứng PHẢI là kiểu phần cứng phù hợp được ấn định bởi IA_NA, như mô tả trong RFC 826. Kiểu phần cứng được lưu trữ ở dạng thứ tự byte mạng. Địa chỉ tầng liên kết được lưu trữ ở dạng chuẩn như mô tả trong RFC 2464. H ì nh vẽ sau đây mô tả định dạng của DUID-LL: Việc lựa chọn giao diện mạng có thể được hoàn thành khi mà giao diện này cung cấp một địa chỉ tầng liên kết duy nhất và vĩnh cửu liên kết với thiết bị mà DUID-LL được tạo ra trên đó. DUID-LL tương tự N Ê N được sử dụng để cấu hình tất cả các giao d iện mạng nối tới thiết bị bất kể việc địa chỉ tầng liên kết của giao d iện này có được sử dụng để tạo ra DUID-LLT hay không. DUID-LL được khuyến nghị đối với các thiết bị có giao diện mạng kết nối vĩnh cửu với 1 địa chỉ tầng liên kết và không có thiết bị lưu trữ ghi được không ổn định. DUID-LL KHÔNG ĐƯỢC sử dụng bởi các máy khách hoặc máy chủ mà không chứng tỏ được liệu giao diện mạng có được liên kết vĩnh cửu với thiết bị mà máy khách DHCP chạy trên đó hay không. 10. Tập định danh Một IA là một cấu trúc mà qua đó máy khách và máy chủ có thể định danh, nhóm hay quản lý một tập các địa chỉ IPv6. Mỗi IA bao gồm 1 IAID và thông tin cấu hình kết hợp. Máy khách PHẢI kết hợp í t nhất 1 IA với mỗi giao diện mạng của nó, giao diện mà theo đó nó sẽ yêu cầu việc ấn định các địa chỉ IPv6 từ máy chủ DHCP. Máy khách sử dụng các IA được ấn định cho 1 giao diện để có thông tin cấu hình từ máy chủ cho giao diện này. Mỗi IA PHẢI được kết hợp chính xác với 1 giao diện. IAID định danh duy nhất cho IA và PHẢI được chọn là duy nhất trong số các IAID trên máy khách. IAID được chọn bởi máy khách. Khi một IA được sử dụng bởi máy khách, thì IAID của IA này PHẢI phù hợp thông qua việc khởi động lại các máy khách DHCP. Máy khách có thể duy trì sự phù hợp này bằng cách lưu trữ IAID trên bộ nhớ không ổ n định hoặc sử dụng thuật toán phù hợp để s ả n sinh ra IAID tương tự khi mà cấu hình của máy khách chưa bị thay đổi. Có thể không có cách nào cho máy khách duy trì sự phù hợp của các IAID nếu như nó không có bộ lưu trữ không ổn định và cấu hình phần cứng của máy khách thay đổi. Thông tin cấu hình trong một IA bao gồm một hoặc nh i ều địa chỉ IPv6 cùng với các khoảng thời gian T1 và T2 cho IA. Điều 22.4 sẽ mô tả biểu diễn của một IA trong bản tin DHCP. Mỗi địa chỉ trong một IA có thời gian tồn tại mong muốn và thời gian tồn tại hiệu lực, như quy định trong RFC 2462. Thời gian t ồ n tại được chuyển từ máy chủ DHCP đến máy khách trong tùy chọn IA. Thời gian tồn tại áp dụng đối với việc sử dụng các địa chỉ IPv6, như được mô tả trong mụ c 5.5.4 của RFC 2462. 11. Lựa chọn địa chỉ để ấn định cho một IA Máy chủ lựa chọn các địa chỉ cần được ấn định cho IA theo chính sách ấn định địa chỉ đã được quy định bởi người quản lý máy chủ và thông tin cụ th ể máy chủ xác định về máy khách từ tổ hợp các nguồn sau đây: - Liên kết mà máy khách n ố i tới. Máy chủ xác định liên kết như sau: • Nếu máy chủ nhận bản tin trực tiếp từ máy khách và địa chỉ nguồn trong sơ đồ IP mà bản tin được tiếp nhận là địa chỉ liên kết cục bộ, th ì máy khách trên cùng liên kết mà mà giao diện qua đó bản tin nhận được đã được liên kết vào. • Nếu máy chủ nhận bản tin từ nút mạng trung gian gửi chuyển tiếp, thì máy khách trên cùng liên kết mà giao diện liên kết tới (được định danh bởi trường link-address field trong bản tin từ nút mạng trung gian) . • N ế u máy chủ nhận bản tin trực tiếp từ máy khách và địa chỉ nguồn trong sơ độ IP mà bản tin được nhận không phải địa chỉ liên kết cục bộ, thì máy khách trên liên kết được định danh bởi địa chỉ nguồn trong sơ đồ IP (chú ý rằng trường hợp này có thể chỉ xảy ra nếu máy chủ được kích hoạt để cho phép sử dụng việc chuyển bản tin unicast bởi máy khách và máy khách gửi bản tin mà việc chuyển unicast là được phép). - DUID được cung cấp bởi máy khách. - Các thông tin khác trong các tùy chọn được máy khách cung cấp. - Thông tin khác trong các tùy chọn được nút mạng trung gian cung cấp. Bất cứ địa chỉ nào được ấn định bởi máy chủ đều dựa trên việc định danh EUI-64 PHẢI bao gồm một định danh giao diện với “u” (universal/local) và “g” (individual/group) bit từ tập định danh giao diện phù h ợ p như chỉ ra trong 2.5.1 của RFC 2373:1998. Máy chủ KHÔNG ĐƯỢC ấn định địa chỉ dữ trừ cho các mục đích khác. V í dụ, máy chủ KHÔNG ĐƯỢC ấn định các địa chỉ anycast dự phòng từ tập con nào như định nghĩa trong RFC 2526. 12. Quản lý các địa chỉ tạm thời Máy khách có thể yêu cầu ấn định các địa chỉ tạm thời (xem RFC 3041 về khái niệm địa chỉ tạm thời). DHCPv6 xử lý đối với các địa chỉ tạm thời không có sự khác biệt. DHCPv6 không quan tâm chi tiết các thông số về địa chỉ tạm thời như thời gian tồn tại, cách máy khách sử dụng các địa chỉ tạm thời, các quy tắc tạo địa chỉ tạm thời liên tiếp... Các máy khách yêu cầu địa chỉ tạm thời và máy chủ ấn định cho nó. Các địa chỉ tạm thời được thực hiện trong tùy chọn IA_TA (xem 22.5). Mỗi tùy chọn IA_TA chứa nhiều nhất 1 địa chỉ tạm thời cho mỗi tiền tố (prefix) trên liên kết mà máy khách nối tới. Không gian số IA I D cho tùy chọn IA_TA là tách biệt với tùy chọn IA_NA. Máy chủ CÓ TH Ể cập nhật DNS cho 1 địa chỉ tạm thời như mô tả trong phần 4 của RFC 3041. 13. Việc truyền các bản tin của một máy khách Trừ khi có các quy định khác, hoặc trong một tiêu chuẩn mô tả cách thức IPv6 được thực hiện trên một kiểu liên kết cụ thể (với các kiểu liên kết không hỗ trợ multicast), máy khách sẽ gửi các bản tin DHCP đến AII_DHCP_Relay_Agents_and_Servers. Máy khách sử dụng multicast để đến tất cả các máy chủ hoặc một máy chủ cụ thể. Máy chủ cụ thể được định danh bởi quy định DUID của máy chủ trong tùy chọn Server Identi f ier (xem 22.3) trong bản tin của máy khách (tất cả các máy chủ sẽ nhận bản tin n à y nhưng chỉ máy chủ được chỉ r a mới phản hồi). Tất c ả các má y chủ được chỉ ra bằng cách không cung cấp tùy chọn này. Một máy khách có thể gửi một số bản tin trực tiếp đến máy chủ sử dụng unicast, như mô tả trong 22.12. 14. Độ tin cậy của việc trao đổi bản tin do máy khách khởi tạo Các máy khách DHCP chịu trách nhiệm về việc chuyển các bản tin 1 cách tin cậy khi trao đổi các bản tin khởi tạo từ máy khách như mô tả trong Điều 17 và 18. Nếu máy khách DHCP không nhận được đáp ứng mong đợi từ máy chủ, máy khách PHẢI phát lại bản tin của n ó . Phần này mô tả việc phát lại được máy khách sử dụng trong khi trao đổi bản tin do máy khách khởi tạo. Chú ý rằng th ủ tục mô tả trong phần này có sự điều chỉnh nh ỏ khi sử dụng với bản tin Solicit. Thủ tục được điều chỉnh được mô tả trong 17.1.2. Máy khách bắt đầu trao đổi bản tin bằng cách phát 1 bản tin đến máy chủ. Bản tin kết thúc khi máy khách nhận được (các) phản hồi tương ứng từ (các) máy chủ hoặc khi việc trao đổi bản tin bị xem là thất bại theo cơ ch ế phát lại mô tả dưới đây. Hành vi phát lại của máy khách được kiểm soát và mô tả bởi các biến sau đây: RT Hết giờ phát lại (Retransmission timeout) IRT Thời gian phát lại lần đầu ( Initial retransmission time) MRC Số lần phát l ại tối đa (Maximum retransmission count) MRT Thời gian phát lại tối đa (Maximum retransmission time) MRD Khoảng thời gian phát lại tối đa (Maximum retransmission duration) RAND Hệ số ngẫu nhiên (Randomization f actor) Với mỗi bản tin phát hoặc phát lại, máy khách thiết lập RT theo các quy tắc dưới đây. Nếu RT hết hiệu lực trước khi việc trao đổi bản tin kết thức thì máy khách tính lại RT và phát lại bản tin. Mỗi phép tính toán RT mới bao gồm một hệ số ngẫu nhiên (RAND), là một số ngẫu nhiên được chọn bằng một phân bố chuẩn giữa -0,1 và 0,1. Hệ số ngẫu nhiên này được đưa vào để gi ả m thiểu sự đồng bộ của các bản tin do máy khách DHCP phát đi. Thuật toán sử dụng để chọn số ngẫu nhiên không cần quá bảo mật. Thuật toán NÊN sinh được một chuỗi các số ngẫu nhiên từ mỗi yêu cầu của máy khách DHCP. RT đối với lần phát bản tin đầu tiên được dựa trên IRT: RT = IRT + RAND*IRT RT đối với mỗi lần phát bản tin tiếp theo dựa trên giá trị trước đó của RT: RT = 2*RTprev + RAND*RTprev MRT xác định biên trên của giá trị RT (bất kể ngẫu nhiên được thêm vào do sử dụng RAND). Nếu MRT có giá trị 0, thì không có giá trị giới hạn trên của RT. Nói cách khác: Nếu (RT > MRT) th ì RT = MRT + RAND*MRT MRC xác định biên trên về số lần máy khách có thể phát lại bản tin. Trừ khi MRC = 0, còn việc trao đổi bản tin bị lỗi khi máy khách đã phát hết MRC lần. MRD xác định biên trên về độ dài thời gian máy khách phát lại 1 bản tin. Trừ khi MRD = 0, việc trao đổi bản tin bị lỗi khi đã quá MRD giây kể từ khi máy khách phát bản tin đầu tiên. Nếu cả MRC và MRD khác 0, việc trao đổi bản tin bị lỗi khi một trong các điều kiện đặt ra ở trên được thỏa mãn. Nếu cả MRC và MRD bằng 0, máy khách tiếp tục phát bản tin cho đến khi nó nhận được ph ả n hồi. 15. Hiệu lực của bản tin Máy khách và máy chủ NÊN hủy các bản tin chứa các tùy chọn mà không được phép xuất hiện trong bản tin. Ví dụ, tùy chọn IA không được phép xuất hiện trong bản tin Information-request. Máy khách và máy chủ CÓ THỂ chọn để tr í ch thông tin từ bản tin này nếu thông tin có ích cho bên nhận. Máy chủ PHẢI hủy các bản tin So l icit, Confirm, Rebind hay Information-request bất kỳ mà n ó nhận được với địa chỉ đ í ch unicast. Hiệu lực của bản tin dựa trên việc xác thực DHCP trong Điều 21.4.2. Nếu máy chủ nhận 1 bản tin chứa các tùy chọn mà nó không cần (như bản tin Information-request kèm tùy chọn IA), thiếu các tùy chọn mà nó cần hoặc có mà không phù hợp, nó CÓ THỂ gửi bản tin Reply (hoặc Advertise phù hợp) với tùy chọn Server Identi f ier, tùy chọn Client Identi f ier nếu nó được bao g ồ m trong bản tin này và tùy chọn Status Code với trạng th á i UnSpecFail. 15.1. Sử dụng các Transaction ID Trường “transaction-id” giữ giá trị được sử dụng bởi máy khách và máy chủ để đồng bộ các đáp ứng của máy chủ với các bản tin của máy khách. Máy khách NÊN tạo ra một s ố ngẫu nhiên không dễ dự đoán đ ể sử dụng làm Transaction ID cho mỗi bản tin mà nó gửi đi. Chú ý rằng nếu máy khách tạo ra một định danh giao dịch dễ đoán thì nó có thể dễ bị tấn công gây tổn hại. Máy khách PHẢI giữ Transaction ID không đổi khi phát lại bản tin. 15.2. Bản t i n Solicit Máy khách PHẢI hủy bất kỳ bản tin Solicit nào nhận được. Máy chủ PHẢI hủy bất cứ bản tin Solicit nào không chứa tùy chọn Client Identi fi er hoặc không bao gồm tùy chọn Server Identifier. 15.3. Bản tin Advertise Máy khách PH Ả I hủy bất kỳ bản tin A d vertise nào thỏa mãn một trong các điều kiện sau: - bản tin không chứa tùy chọn Server Identifier. - bản tin không bao gồm tùy chọn Client Identifier. - nội dung của tùy chọn Client Identifier không phù h ợ p với DUID của máy khách. - giá trị trường “transaction-id” không phù hợp với giá trị mà máy khách sử dụng trong bản tin Solicit. Máy chủ và nút mạng trung gian PHẢI hủy các bản tin Advertise nhận được bất kỳ. 15.4. Bản tin Request Máy khách PH Ả I hủy bất kỳ bản tin Request nào nhận được. Máy chủ PHẢI hủy các bản tin Request nhận được bất kỳ th ỏ a mãn một trong các điều kiện sau: - bản tin không bao gồm tùy chọn Server Identifier. - nội dung tùy chọn Server Identifier không phù hợp DUID của máy khách. - bản tin không bao gồm lựa Client Identifier. 15.5. Bản tin Confirm Máy khách PHẢI hủy bất kỳ bản tin Confirm nào nhận được. Máy chủ PHẢI hủy các bản tin Confirm nhận được bất kỳ mà không chứa tùy chọn Client Identifier hoặc không chứa tùy chọn Server Identifier. 15.6. Bản tin Renew Máy khách PHẢI hủy bất kỳ bản tin Renew nào nhận được. Máy chủ PHẢI hủy các bản tin Renew nhận được bất kỳ thỏa mãn một trong các điều kiện sau: - Bản tin không bao gồm tùy chọn Server Identifier. - Nội dung của tùy chọn Server Identifier không phù hợp định danh của máy chủ. - Bản tin không bao gồm tùy chọn Client Identifier. 15.7. Bản tin Rebind Máy khách PHẢI h ủ y bất kỳ bản tin Rebind nào nhận được. Máy chủ PHẢI hủy các bản tin Redind nhận được bất kỳ mà không chứa tùy chọn Client. 15.8. Bản tin Decline Máy khách PHẢI hủy bất kỳ Bản tin Decline nào nhận được. Máy chủ PHẢI loại bỏ các Bản tin Decline nhận được thỏa mãn một trong các điều kiện sau đây: - Bản tin không bao hàm tùy chọn Server Identifier. - Các nội dung trong tùy chọn Server Identi fi er không phù hợp với định danh của máy chủ. - Bản tin không bao gồm tùy chọn Server Identifier máy khách. 15.9. Bản tin Release Máy khách PHẢI hủy bất kỳ Bản tin Release nào nhận được. Máy chủ PHẢI loại bỏ các bản tin Release nhận được khi thỏa một trong các điều kiện sau đây: - Bản tin không bao gồm tùy chọn Server Identifier. - Các nội dung trong tùy chọn Server Identifier không phù hợp với định danh của máy chủ. - Bản tin không bao gồm tùy chọn Server Identi f ier máy khách. 15.10. Bản tin Reply Máy khách PHẢI hủy bất k ỳ Bản tin Reply nào nhận được ở các điều kiện sau đây: - Bản tin không bao gồm tùy chọn Server Identifier. - Trường “transaction-id” trong bản tin không phù hợp với giá trị được sử dụng trong bản tin ban đầu. Nếu máy khách bao gồm tùy chọn Server Identifier trong bản tin ban đầu, bản tin Reply PHẢI chứa một tùy chọn Client Identifier và các nội dung của tùy chọn Client Identifier PHẢI phù hợp với DUID của máy khách. Hoặc nếu máy khách không chứa tùy chọn Client Identifier trong bản tin gốc thì bản tin Reply cũng KHÔNG ĐƯỢC chứa tùy chọn Client Ident if ier. Máy chủ và các nút mạng trung gian PHẢI loại bỏ tất cả bản tin Reply nhận được. 15.11. Bản tin Reconfigure Máy chủ và nút mạng trung gian PHẢI hủy bất kỳ Bản tin Reconfigure nào nhận được. Máy khách PHẢI loại bỏ các bản tin Reconfigure khi thỏa mãn một trong các điều kiện sau đ â y: - Bản tin không PHẢI là unicast tới máy khách. - Bản tin không chứa tùy chọn Server Identifier. - Tùy chọn Server Identifier trong bản tin không chứa DUID của máy khách. - Bản tin không chứa tùy chọn Reconfigure Message và trường msg-type PHẢI có giá trị hợp lệ. - Bản tin có chứa tùy chọn IA bất kỳ và trư ờ ng msg-type trong tùy chọn Reconfigure Message là INFORMATION-REQUEST. - Bản tin không chứa xác thực DHCP: • Bản tin không chứa tùy chọn Authentication. • Bản tin không qua được quá trình xác thực được thực hiện bởi máy khách. 15.12. Bản tin Information-request Máy khách PHẢI hủy bất kỳ Bản tin Information-request nào nhận được. Máy chủ PHẢI loại b ỏ bản tin Information-request nhận được th ỏ a một trong các điều kiện dư ớ i đây: - Bản tin có chứa tùy chọn Server Identifier nhưng DUID không phù hợp với DUID của máy chủ. - Bản tin có chứa một tùy chọn IA. 15.13. Bản tin Relay-forward Máy khách PHẢI hủy bất kỳ Bản tin Relay-forward nào nhận được. 15.14. Bản tin Relay-Reply Máy khách và máy chủ PHẢI hủy bất kỳ bản tin Relay-reply nào nhận được. 16. Địa chỉ nguồn máy khách và việc lựa chọn giao diện Khi máy khách gửi một bản tin DHCP đến địa chỉ AII_DHCP_Relay_Agents_and_Servers, nó NÊN gửi bản tin thông qua giao diện đã yêu cầu thông tin cấu hình. Tuy nhiên, máy khách CÓ THỂ gửi bản tin thông qua giao diện khác trên cùng liên kết khi máy khách chắc chắn r ằ ng 2 giao diện trên cùng một liên k ết. Máy khách PHẢI sử dụng địa chỉ liên kết nội bộ được ấn định cho giao diện mà nó đang yêu cầu thông tin cấu hình như địa chỉ nguồn trong phần mào đầu của gi ả n đồ IP. Khi máy khách gửi trực tiếp bản tin DHCP tới máy chủ bằng cách sử dụng unicast (sau khi nhận được tùy chọn Server Unicast từ máy chủ đó), địa chỉ nguồn trong mào đầu của giản đồ IP PHẢI l à địa chỉ được ấn định cho giao diện của máy kh á ch cần lấy thông tin cấu hình v à ph ù hợp để sử dụng bởi máy chủ để phản hồi cho máy khách. 17. Khởi tạo thăm dò của máy chủ DHCP Phần này mô tả cách thức máy khách xác định vị trí của các máy chủ sẽ ấn định địa chỉ cho các IA của máy khách đó. Máy khách có nhiệm vụ tạo ra các IA và yêu cầu máy chủ gán địa chỉ IPv6 cho các IA này. Trước tiên, máy khách tạo ra một IA và g án nó vào một IAID, sau đ ó phát bản tin Solicit có chứa một tùy chọn IA mô tả về IA. Máy chủ có thể ấ n định các địa chỉ cho các IA bằng cách phản hồi cho máy khách một bản tin Advertise. Sau khi nhận được bản tin, máy khách sẽ khởi tạo quá trình trao đổi cấu hình như mô tả trong Điều 18. Nếu như máy khách chấp nhận bản tin Reply với việc ấn định địa chỉ đã cam kết và các tài nguyên khác để đáp ứng với bản tin Solicit, máy khách thì máy khách bao hàm tùy chọn Rapid Commit (xem Điều 22.14) trong bản tin Solicit. 17.1. Hành vi của máy khách Máy khách sử dụng bản tin Solicit để khám phá các máy chủ DHCP đ ã được cấu hình để ấn định địa chỉ hoặc gửi lại các thông số cấu hình khác trong liên kết được máy khách nối tới. 17.1.1. Tạo các bản tin Solicit Máy khách thiết lập trường “msg-type” vào SOLICIT. Máy khách khởi tạo một Transaction ID và chèn giá trị này vào trường “transaction-id”. Máy khách PHẢI bao hàm tùy chọn Client Identifier để định danh chính nó cho máy chủ. Máy khách chứa các tùy chọn IA cho các IA m à nó muốn máy chủ ấn định địa chỉ cho các IA này. Máy khách CÓ THỂ bao hàm các địa chỉ trong các IA như một gợi ý cho máy chủ về các địa chỉ máy khách có tham chiếu. Máy khách KHÔNG ĐƯỢC bao hàm bất kỳ tùy chọn nào khác trong bản tin Solicit việc định nghĩa các tùy chọn riêng. Máy chủ sử dụng các tùy chọn IA_NA để yêu cầu ấn định địa chỉ lâu dài và sử dụng các tùy chọn IA_TA để yêu cầu ấn định các địa chỉ tạm thời. Các tùy chọn IA_NA hay IA_TA hoặc sự kết hợp của cả hai có thể được bao hàm trong các bản tin DHCP. Máy chủ NÊN bao hàm tùy chọn Option Request (xem Điều 22.7) để chỉ ra các tùy chọn mà máy khách mong muốn nhận được. Máy khách CÓ THỂ chứa thêm các trường hợp đặc biệt của các phương thức nhận tin đó là sự nhận dạng trong tùy chọn Option Request với các giá trị dữ liệu như một gợi ý cho máy chủ về giá trị của các thông số mà máy khách muốn nhận. Máy khách bao hàm tùy chọn Reconfigure Accept (xem Điều 22.20) nếu máy khách sẵn sàng chấp nhận các bản tin Recon fi gure từ máy chủ. 17.1.2. Truyền các bản tin Solicit Bản tin Solicit đầu tiên từ máy khách trên giao diện PHẢI bị trễ lại một khoảng ngẫu nhiên giữa 0 và SOL_MAX_DELAY. Trong trường hợp này, bản tin Solicit được phát khi DHCP khởi tạo bởi IPv6 Neighbor Discovery, thời gian trễ cho phép để đợi sau khi IPv6 Neighbor Discovery yêu cầu giao thức tự động cấu hình địa chỉ có giữ trạng thái (xem Điều 5.5.3 của RFC 2462). Thời gian trễ ngẫu nhiên bất đồng bộ với máy khách khởi động ở cùng thời điểm (ví dụ, sau khi hết điện). Máy khách phát bản tin theo Điều 14, sử dụng các tham số sau: IRT SOL_TIMEOUT MRT SOL_MAX_RT MRC 0 MRD 0 Nếu máy khách có bao hàm tùy chọn Rapid Commit trong bản tin Solicit của n ó , th ì máy chủ kết thúc quá trình đợi ngay khi nhận được bản tin Reply có tùy chọn Rapid Commit. Nếu máy khách đợi bản tin Advertise, cơ chế trong Điều 14 bị điều ch ỉ nh để sử dụng khi truyền các bản tin Solicit. Việc trao đổi bản tin không kết thúc khi nhận bản tin Advertise trước khi hết RT. V à máy khách thu thập các bản tin Adver t ise cho đến khi hết RT. Đồng thời, RT đầu tiên PHẢI được tùy chọn lớn hơn IRT bằng cách chọn RAND lớn hơn 0. Máy khách PHẢI thu thập các bản tin Advertise trong RT giây đầu tiên, trừ khi nó nhận được bản tin Advertise với giá trị tham chiếu bằng 255. Giá trị tham chiếu được thực hiện trong tùy chọn Pre f erence (Điều 22.8). Bản tin Advertise bất kỳ không được bao hàm tùy chọn đều được xem là có giá trị tham chiếu bằng 0. Nếu máy khách nhận được bản tin Advertise có tùy chọn Preference với giá trị tham chiếu bằng 255, thì máy khách ngay lập tức bắt đầu việc trao đổi bản tin khởi tạo từ máy khách (như mô tả trong Điều 18) bằng cách g ử i b ả n tin Request đến máy chủ mà từ đó bản tin Advertise được nhận. Nếu máy khách nhận bản tin Advertise không chứa tùy chọn Pre f erence có giá trị tham chiếu bằng 255, máy khách sẽ tiếp tục đợi đến khi hết RT đầu tiên. Nếu hết RT đầu tiên và máy khách nhận được bản tin Advertise, th ì máy khách NÊN tiếp tục việc trao đổi bản tin khởi tạo từ máy khách bằng cách gửi bản tin Request. Nếu máy khách không nhận được bất kỳ bản tin Advertise nào trước khi hết RT, thì n ó bắt đ ầ u cơ chế phát lại như trong Điều 14. Máy khách kết thúc quá trình phát lại ngay khi nó nhận bản tin Advertise và máy khách tác động trên bản tin Advertise mà không đợi bản tin Advertise b ổ sung. Máy khách DHCP NÊN chọn MRC và MRD là 0. Nếu máy khách DHCP được cấu hình với MRC hay MRD thiết lập khác 0, nó PHẢI dừng việc cấu hình giao diện nếu việc trao đ ổ i bản tin bị lỗi. Sau khi máy khách DHCP kết thúc việc cố c ấ u hình giao diện, nó NÊN khởi động lại quá trình cấu hình lại một số sự kiện như đầu vào người sử dụng, hệ thống khởi động lại hay khi máy khách được chuyển sang liên kết mới. 17.1.3. Nhận các bản tin Advertise Máy khách PHẢI b ỏ qua bản tin Advertise có bao hàm tùy chọn Status Code chứa giá trị NoAddrsAvail, trừ khi máy khách CÓ THỂ hiển thị bản tin trạng thái tới người sử dụng. Khi nhận một hay nhiều bản tin Advertise phù hợp, máy khách lựa chọn một hay nhiều bản tin Advertise dựa trên các tiêu chí sau: - Các bản tin Advertise này có giá trị tham chiếu máy chủ cao nhất thích hợp hơn tất cả các bản tin Advertise khác. - Trong một nhóm các bản tin có cùng giá trị tham chiếu máy chủ giống nhau, máy khách CÓ THỂ lựa chọn các máy chủ mà bản tin Advertise của nó phổ biến thông tin quan t â m đến máy khách này. Ví dụ, máy khách có thể chọn máy chủ trả về nội dung kèm theo các tùy chọn cấu hình quan tâm tới máy khách. - Máy khách CÓ THỂ chọn máy chủ ít phù hợp hơn nếu máy chủ n à y có tập các tham số được ph ổ biến như là các địa chỉ khả d ụng được phổ biến trong các IA. Khi một máy khách đã lựa chọn bản tin Advertise, máy khách sẽ lưu giữa thông tin về mỗi máy chủ, như là giá trị tham chiếu của máy chủ, các địa chỉ được phổ biến... Nếu máy khách cần lựa chọn máy chủ dự phòng trong trường hợp m á y chủ đã được chọn không phản hồi, thì máy khách chọn máy chủ tiếp theo theo các tiêu chí cho ở trên. 17.1.4. Nhận các bản tin Reply Nếu máy khách bao hàm tùy chọn Rapid Commit trong bản tin Solicit, nó sẽ chờ bản tin Reply đáp ứng chứa tùy chọn Rapid Commit. Máy khách hủy các bản tin Reply b ấ t kỳ nó nhận được mà không bao hàm tùy chọn Rapid Commit. Nếu máy khách nhận được bản tin Reply phù hợp chứa tùy chọn Rapid Commit, nó xử lý bản tin như mô tả trong Điều 18.1.8. Nó không nhận bản tin Reply và không nhận bản tin Advertise phù hợp, máy khách xử lý bản tin Advertise như mô tả trong Điều 17.1.3. Nếu máy khách nhận bản tin Reply tiếp theo có ch ứ a tùy chọn Rapid Commit, nó sẽ: - x ử lý bản tin Reply như mô tả trong Điều 18.1.8 và hủy các bản tin Reply bất kỳ nhận được để đáp ứng với bản tin Request, hoặc - xử lý các bản tin Reply nh ậ n được bất kỳ để đáp ứng với bản tin Request và hủy bản tin Repl y chứa tùy chọn Rapid Commit. 17.2. Hành vi của máy chủ Máy chủ gửi bản tin Advertise để đáp ứng với các bản tin Solicit phù hợp nó nh ậ n được để thông báo về độ khả dụng của máy chủ đối với máy khách. 17.2.1. Nhận các bản tin Solicit Máy chủ xác định thông tin về máy khách và định vị của nó như mô tả trong Điều 11 và kiểm tra chính sách quản lý của nó về việc đáp ứng v ớ i máy khách. Nếu máy chủ không được phép phản hồi cho máy khách thì máy chủ sẽ hủy bản tin Solicit. Ví dụ, nếu chính sách quản lý của máy chủ quy định rằng nó ch ỉ được đáp ứng máy khách mà chấp nhận bản tin Reconfigure và máy khách cho thấy rằng có tùy chọn Reconfigure Accept trong bản tin Solicit thì nó sẽ không chấp nhận bản tin Reconfigure và máy chủ hủy bản tin Solicit. Nếu máy khách bao hàm tùy chọn Rapid Commit trong bản tin Solicit và máy chủ đã cấu hình để phản hồi với việc ấn định các địa chỉ đã cam kết và các tài nguyên khác, máy chủ phản hồi bản tin Solicit bằng bản tin Reply như mô tả trong Điều 17.2.3. Cách khác, máy chủ b ỏ qua tùy chọn Rapid Commit và xử lý phần còn lại của bản tin khi không có tùy chọn Rapid Commit. 17.2.2. Tạo và truyền các bản tin Advertise Máy chủ thiết lập trường “msg-type” trong bản tin ADVERTISE và sao chép tất cả nội dung trường transaction-id từ bản tin Solicit nhận được từ máy khách vào bản tin Advertise. Máy chủ bao hàm đ ị nh danh máy chủ của chính nó trong một tùy chọn Server I dent i fier và máy chủ sao chép định danh máy khách từ bản tin Solicit vào bản tin Advertise. Máy chủ C Ó TH Ể thêm tùy chọn Pre f erence để mang giá trị cho bản tin Advertise. Việc triển khai máy chủ NÊN cho phép người quản trị thiết lập giá trị tham chiếu của máy chủ. Giá trị tham chiếu của máy chủ PHẢI được thiết lập mặc định là 0 trừ khi đã được cấu hình bởi người quản tr ị máy chủ. Máy chủ bao hàm tùy chọn Reconfigure Accept nếu máy chủ muốn yêu cầu máy khác chấp nhận các bản tin Reconfigure. Máy chủ bao hàm các tùy chọn mà nó sẽ tr ả về cho máy khách trong bản tin Reply sau đó. Thông tin trong các tùy chọn này có thể được máy khách sử dụng để lựa chọn máy chủ nếu máy khách nhận được nhiều hơn một bản tin Advertise. Nếu máy khách đã bao hàm tùy chọn Option Request trong bản tin Solicit, th ì máy chủ bao hàm các tùy chọn trong bản tin Advertise chứa các tham số cấu hình cho tất cả các l ự a chọn được định danh trong tùy chọn Option Request mà máy chủ đã cấu hình để gửi cho máy khách. Máy ch ủ CÓ THỂ trả về các tùy chọn bổ sung cho máy khách nếu nó được cấu hình để làm điều đó. Máy chủ PHẢI nhận thức được về các khuyến nghị về kích thước gói và việc sử dụng phân mảnh trong Điều 5 của TCVN 9802-1:2013. Nếu bản tin Solicit từ máy khách bao hàm một hoặc nhiều tùy chọn IA, máy chủ PHẢI bao hàm các tùy chọn IA trong bản tin Advertise chứa các địa chỉ bất kỳ sẽ được ấn định cho IA chứa trong bản tin Solicit từ máy khách. Nếu máy khách đã bao hàm các địa chỉ trong các IA ở bản tin Solicit thì máy chủ sử dụng các địa chỉ này như là hướng dẫn về địa chỉ mà máy khách mong muốn nhận được. Nếu máy chủ không được ấn định địa chỉ cho các IA bất kỳ trong bản tin Request sau đó từ máy khách, thì máy chủ PHẢI gửi bản tin Advertise đến máy khách ch ỉ chứa tùy chọn Status Code với mã NoAddrsAvail và bản tin trạng thái cho người sử dụng, tùy chọn Server Identifier kèm DUID của máy chủ và tùy chọn Client Identifier kèm DUID của máy khách. Nếu bản tin Solicit được nhận trực tiếp từ máy chủ, máy chủ unicast bản tin Advertise trực ti ế p đến máy khách sử dụng địa chỉ trong trường địa chỉ nguồn từ giản đồ IP mà bản tin Solicit nhận được. Bản tin Advertise PHẢI được unicast trên liên kết nơi mà bản tin Solicit được nhận. Nếu bản tin Solicit được nhận trong bản tin Relay-forward, thì máy chủ xây dựng một bản tin Relay- reply với bản tin Advertise trong t ả i tin của tùy chọn “relay-message”. Nếu bản tin Relay-forward bao hàm tùy chọn lnterface-id, thì máy chủ sao chép tùy chọn này vào bản tin Relay-reply. Máy chủ unicast bản tin Relay-reply trực tiếp đến nút mạng trung gian sử dụng địa chỉ trong trường địa chỉ nguồn t ừ giản đồ IP nơi mà bản tin Relay-forward được nhận. 17.2.3. Tạo và truyền các bản tin Reply Máy chủ PHẢI cam kết việc ấn định địa chỉ bất kỳ hoặc bản tin thông tin cấu hình khác trước khi gửi bản tin Reply cho máy khách để phản hồi cho bản tin Solicit. Máy chủ bao hàm tùy chọn Rapid Commit trong bản tin Reply để chỉ ra rằng b ả n tin Reply là để phản hồi cho bản tin Solicit. Máy chủ bao hàm tùy chọn Reconfigure Accept nếu máy chủ muốn yêu cầu máy khách chấp nhận các bản tin Reconfigure. Máy chủ tạo ra bản tin Reply để qua đó nhận bản tin Request như mô tả trong Điều 18.2.1. Máy chủ phát bản tin Rep l y như mô tả trong 18.2.8. 18. Trao đổi cấu hình khởi tạo từ máy khách Máy khách khởi tạo việc trao đổi bản tin với máy chủ hoặc các máy chủ để yêu cầu hoặc cập nhật thông tin mà nó quan tâm. Máy khách có thể khởi tạo việc trao đ ổ i cấu hình khi vận hành quá trình cấu hình hệ thống, khi được yêu cầu từ lớp ứng dụng, khi được yêu cầu bởi hệ thống cấu hình địa chỉ tự động không giữ trạng thái hoặc khi yêu cầu tăng thời gian tồn tại của một địa chỉ (các bản tin Renew và Reb i nd). 18.1. Hành vi của máy khách Máy khách sử dụng các bản tin Request, Renew, Rebind, Release và Decline trong chu kỳ hoạt động b ì nh thường của các địa chỉ. Nó sử dụng bản tin Confirm để đánh giá hiệu lực của các địa chỉ khi n ó chuyển đến một liên kết mới. Và nó sử dụng bản tin Information-Request khi nó cần thông tin cấu hình mà không cần địa chỉ. Nếu máy khách có địa chỉ nguồn với phạm vi đủ để máy chủ sử dụng làm địa chỉ trả về và máy khách nhận đ ư ợc tùy chọn Server Unicast (xem 22.12) từ máy chủ thì phái khách NÊN gửi unicast một bản tin Request, Renew, Release hay Decline bất kỳ đến máy chủ. 18.1.1. Tạo và truyền các bản tin Request Máy khách sử dụng bản tin Request để gửi các IA kèm địa chỉ và nhận thông tin cấu hình khác. Máy khách bao hàm một hoặc nhiều tùy chọn IA trong bản tin Request. Sau đó máy chủ trả về các địa chỉ và thông tin khác về các IA cho máy khách trong các tùy chọn IA trong bản tin Reply. Máy khách tạo ra một ID giao dịch và chèn giá trị này trong trường “transaction-id”. Máy khách đặt định danh của máy chủ đích trong tùy chọn Server Identi f ier. Máy khách PHẢI bao hàm tùy chọn Client Identifier để tự định danh nó với máy chủ. Máy khách thêm các tùy chọn phù hợp khác bất kỳ, bao gồm một hoặc nhiều tùy chọn IA (nếu máy khách yêu cầu máy chủ ấn định cho n ó một số địa chỉ mạng). Máy khách PHẢI bao hàm 1 tùy chọn Option Request (xem 22.7) để chỉ ra các mà máy khách muốn nhận được. Máy khách CÓ THỂ bao hàm các tù y chọn với các giá trị như là các hướng dẫn đối với máy chủ về các giá trị tham số mà máy khách muốn được trả về. Máy khách bao hàm một tùy chọn Recon f igure Accept (xem 22.20) để chỉ ra liệu máy khách có sẵn sàng chấp nhận các bản tin Reconfigure từ máy chủ hay không. Máy khách phát bản tin theo Điều 14 sử dụng các thông số sau: IRT REQ_T I MEOUT MRT REQ_MAX_RT MRC REQ_MAX_RC MRD 0 Nếu việc trao đổi bản tin bị lỗi, máy khách sẽ hành động dựa trên chính sách nội bộ của nó. Ví dụ về các hành vi của máy khách có thể bao gồm: - Lựa chọn máy chủ khác từ danh sách các máy chủ đã có của máy khách; ví dụ, các máy chủ đáp ứng với bản tin Advertise. - Khởi tạo quá trình phát hiện máy chủ như mô tả trong Điều 17. - K ế t thúc quá tr ì nh cấu hình và báo cáo lỗi. 18.1.2. Tạo và truyền các bản tin Confirm Khi máy khách chuyển đến một liên kết mới, tiền t ố của các địa chỉ được ấn định cho các giao diện trên liên kết có thể kh ô ng còn phù hợp cho liên kết mà máy khách nối tới. Ví dụ về các thời điểm mà máy khách được chuyển đến một liên kết m ớ i bao gồm: - Máy khách khởi động lại. - Máy khách kết nối vật lý với một kết nối bằng dây (cáp). - Máy khách từ chế độ nghỉ (sleep) quay tr ở lại. - Máy khách sử dụng công nghệ vô tuyến làm thay đổi các điểm truy nhập. Trong mọi trường hợp khi máy khách chuyển đến liên kết mới, máy khách PHẢI khởi tạo lại việc trao đổi bản tin Confirm/Reply. Máy khách bao hàm các IA bất kỳ được ấn định ch o giao diện mà nó được chuy ể n đến liên kết mới, cùng với các địa chỉ kết hợp với các IA này, trong bản tin Confirm của nó. Bất cứ đáp ứng nào của máy chủ đều chỉ ra rằng các địa chỉ này thích hợp cho liên kết mà máy khách kết n ố i đến với trạng thái trong bản tin Reply nó phản hồi cho máy khách. Máy khách thiết lập trư ờ ng “msg-type” để khẳng định. Máy khách tạo ra một Transaction ID và chèn giá trị này trong trường “transaction-id”. Máy khách PHẢI bao hàm tùy chọn Client Identi f ier để tự định danh nó với máy chủ. Máy khách bao hàm các tùy chọn IA cho tất cả các IA được ấn định cho giao diện dành cho bản tin Confirm được gửi. Các tùy chọn IA bao gồm tất cả các địa chỉ mà máy khách đang kết hợp với các IA này. Máy khách NÊN thiết lập các trường T1 và T2 trong các tùy chọn IA_NA và các trường preferred-lifetime và valid- li f etime trong tùy chọn IA Address thành 0, bởi vì máy chủ sẽ bỏ qua các trường này. B ả n tin Confirm đầu tiên từ máy khách trên giao diện này PHẢI bị trễ một khoảng thời gian giữa 0 và CNF_MAX_DELAY. Máy khách phát bản tin theo như Điều 14, sử dụng các tham s ố sau: IRT CNF_TIMEOUT MRT CNF_MAX_RT MRC 0 MRD CNF_MAX_RD Nếu máy khách không nhận được phản hồi trước khi quá trình phát bản tin kết thúc, như mô tả trong Điều 14, thì máy khách N Ê N tiếp tục sử dụng địa chỉ IP bất kỳ, sử dụng thời gian tồn tại đã có cho các địa chỉ này và NÊN tiếp tục sử dụng các thông số c ấ u hình nhận được trước đó khác. 18.1.3. Tạo và truyền các bản tin Renew Để tăng thời gian tồn tại cho các địa chỉ kết hợp với IA, máy khách gửi bản tin Renew đến máy chủ mà máy khách nhận địa chỉ từ đ ó trong IA chứa tùy chọn IA cho IA đó. Máy khách bao hàm tùy chọn IA Address trong tùy chọn IA cho các địa chỉ kết hợp với IA. Máy chủ xác định các thời gian tồn tại mới cho các địa chỉ trong IA theo cấu hình quản lý của máy chủ. Máy chủ có thể thêm các địa chỉ mới cho IA. Máy chủ có thể b ỏ các địa chỉ từ IA bằng cách thiết lập các thời gian tồn tại mong muốn và hiệu lực cho các địa chỉ này thành 0. Máy chủ kiểm soát thời gian máy khách liên lạc với máy chủ để tăng thời gian tồn tại trên các địa chỉ được ấn đ ị nh qua các tham số T1 và T2 được ấn định cho IA. Ở thời điểm T1 đối với IA, máy khách khởi tạo việc trao đổi bản tin Renew/Rep l y để tăng thời gian tồn tại trên địa chỉ bất kỳ trong IA. Máy khách bao hàm một tùy chọn IA với tất cả các địa chỉ hiện được ấn định cho IA này trong bản tin Renew của nó. Nếu T1 hoặc T2 được thiết lập bằng 0 bởi máy chủ (cho 1 IA_NA) hoặc không có các thời gian T1 hoặc T2 (với 1 IA_NA) th ì máy khách c ó thể gửi bản tin Renew hoặc Rebind theo ý của máy khách. Máy khách thiết lập trường “msg-type” thành RENEW. Máy khách tạo Transaction ID và chèn giá trị này vào trường “transaction-id”. Máy khách đ ặ t đ ị nh danh của máy chủ đích trong tùy chọn Server Identifier. Máy khách PHẢI bao hàm tùy chọn Client Identifier để tự định danh nó với máy chủ. Máy khách thêm các tùy chọn phù hợp bất kỳ, bao gồm một hoặc nhi ề u tùy chọn IA. Máy khách PHẢI bao hàm danh sách các địa chỉ máy khách hiện có kết hợp với IA trong bản tin Renew. Máy khách PHẢI bao hàm tùy chọn Option Request (xem 22.7) để chỉ ra các tùy chọn mà máy khách mu ố n nhận được. Máy khách CÓ THỂ bao hàm các t ù y chọn với các giá trị như l à hướng dẫn cho máy chủ về các giá trị tham số mà máy khách mong muốn được nhận. Máy khách phát bản tin theo Điều 14, sử dụng các tham số sau: IRT REN TIMEOUT MRT REN_MAX_RT MRC 0 MRD Du y trì thời g ian đến T2 Việc trao đổi bản tin kết thúc khi đến thời gian T2 (xem 18.1.4), tại đó máy khách bắt đầu trao đổi bản tin Rebind. 18.1.4. Tạo và truyền các bản tin Rebind Tại thời điểm T2 cho 1 IA (chỉ đạt được nếu máy chủ mà bản tin Renew được gửi đến tại thời điểm T1 không phản hồi), máy khách khởi tạo việc trao đ ổ i bản tin Rebind/Reply với máy chủ khả dụng bất kỳ. Máy khách bao hàm một tùy chọn IA cùng với tất cả các địa chỉ hiện được ấn định cho IA trong bản tin Rebind của nó. Máy khách thiết lập trường “msg-type” trong REBIND. Máy khách tạo ra một Transaction ID và chèn giá trị này vào trường “transaction-id”. Máy khách PHẢ I bao hàm tùy chọn Client Identi fi er để tự định danh nó với máy chủ. Máy khách thêm các tùy chọn phù hợp bất kỳ, bao gồm một hoặc nhiều tùy chọn IA. Máy khách PHẢI bao hàm danh sách các địa chỉ hiện kết hợp với các IA trong bản tin Rebind. Máy khách PHẢI bao hàm một tùy chọn Option Request (xem 22.7) để chỉ ra các tùy chọn máy khách mong muốn nhận được. Máy khách có thể bao hàm các tùy chọn với giá trị như là hướng d ẫ n máy chủ về các giá trị tham số mà máy khách mong muốn nhận lại. Máy khách phát bản tin theo như Điều 14, sử dụng các tham số sau: IRT REB_TIMEOUT MRT REB_MAX_RT MRC 0 MRD Thời gian còn lại cho đến khi thời gian tồn tại hiệu lực của tất cả các địa chỉ bị hết. Việc trao đổi bản tin kết thúc khi thời g ia n tồn tại hiệu lực của tất cả các địa chỉ được ấn định cho IA quá hạn (xem Điều 10), tại thời điểm này máy khách có một số hành động để lựa chọn, ví dụ: - Máy khách có thể chọn sử dụng bản tin Solicit để định vị máy chủ DHCP mới và gửi bản tin Request kèm IA quá hạn đến máy chủ mới. - Máy khách có th ể có các địa chỉ khác trong các IA khác, vì vậy máy khách có thể chọn hủy IA quá hạn và sử dụng các địa chỉ trong các IA khác. 18.1.5. Tạo và truyền các bản tin I nformat i on-request Máy khách sử dụng bản tin Information-request để nhận được thông tin cấu hình mà không c ầ n ấn định địa chỉ cho nó. Máy khách thiết lập trường “msg-type” trong INFORMATION-REQUEST. Máy khách tạo Transaction ID và chèn giá trị trong trường “transaction-id”. Máy khách NÊN bao hàm tùy chọn Client Identifier để tự định danh nó với máy chủ. Nếu máy khách không bao hàm tùy chọn Client Identifier, máy chủ sẽ không thể trả về các tùy chọn cụ thể cho máy khách hoặc máy chủ có thể chọn không đáp ứng đối với bản tin. Máy khách PHẢI bao hàm tùy chọn Client Identifier nếu bản tin Information-Request được xác thực. Máy khách PHẢI bao hàm tùy chọn Option Request ( xem 22.7) để chỉ ra các tùy chọn máy khách muốn nhận. Máy khách CÓ THỂ bao hàm các tùy chọn kèm theo giá trị như là hướng dẫn về các giá trị tham số cho mà máy khách mong được trả lại. Bản tin Information-request đầu tiên từ máy khách trên giao diện này PHẢI bị trễ một khoảng ngẫu nhiên giữa 0 và INF_MAX_DELAY. Máy khách phát bản tin theo Điều 14, sử dụng các tham số sau: IRT INF_TIMEOUT MRT INF_MAX_RT MRC 0 MRD 0 18.1.6. Tạo và truyền các bản tin Release Để giải phóng 1 hoặc nhiều địa chỉ, máy khách gửi bản tin Release đến máy chủ. Máy khách thiết lập trường “msg-type” trong RELEASE. Máy khách tạo Transaction ID và chèn giá trị trong trường “transaction-id”. Máy khách đặt định danh của máy chủ cấp phát địa chỉ trong tùy chọn Server Identi fi er. Máy khách PHẢI bao hàm tùy chọn Client Identi f i e r để tự định danh nó với máy chủ. Máy khách bao hàm các tùy chọn chứa các IA cho các địa chỉ n ó sắp giải phóng trong trường “options”. Các địa chỉ cần giải phóng PHẢI được bao hàm trong các IA. Các địa chỉ bất kỳ cho các IA mà máy khách muốn tiếp tục sử dụng KHÔNG ĐƯỢC thêm vào các IA. Máy khách KHÔNG ĐƯỢC sử dụng bất cứ địa chỉ sắp giải phóng làm địa chỉ nguồn trong bản tin Release hoặc trong bản tin phát sau đó bất kỳ. Do bản tin Release có thể bị mất, máy khách cần phát lại Release nếu không nhận được bản tin Reply. Tuy nhiên, có các kịch bản mà máy khách không muốn trong thời gian cho phép phát lại thông thường trước khi bị từ ch ố i (ví dụ, mất nguồn). Việc biên dịch NÊN được phát lại nhiều lần, nhưng CÓ THỂ chọn kết th ú c thủ tục phát lại sớm hơn. Máy khách phát lại bản tin theo Điều 14, sử dụng các tham số sau: IRT REL_TIMEOUT MRT 0 MRC REL_MAX_RC MRD 0 Máy khách PHẢI dừng việc sử dụng tất cả các địa chỉ được giải phóng ngay khi máy khách bắt đầu quá trình trao đổi bản tin Release. Nếu các địa chỉ bị giải phóng nhưng bản tin Reply từ máy chủ DHCP bị mất, máy khách sẽ phát lại bản tin Release và máy ch ủ phản hồi b ằ ng bản tin Reply chỉ ra trạng thái NoBinding. Như vậy, máy khách không xử lý bản tin Reply với trạng thái NoBinding trong khi trao đổi bản tin Release nế u nó c ó lỗi. Chú ý rằng nếu máy khách bị lỗi khi giải phóng các địa chỉ, mỗi địa chỉ được ấn định cho IA sẽ được thông báo bởi máy chủ khi thời gian tồn tại của địa chỉ bị quá. 18.1.7. Tạo và truyền các bản tin Decline Nếu máy khách phát hiện một hoặc nhiều địa chỉ được ấn định ch o nó đang được sử dụng bởi một node khác, thì nó s ẽ gửi bản tin Decline đến máy chủ để thông báo rằng địa chỉ này bị nghi ngờ. Máy khách thiết lập trường “msg-type” trong DECLINE. Máy khách tạo Transaction ID và chèn giá trị trong trường “transaction-id”. Máy khách đặt định danh của máy chủ cấp phát địa chỉ trong tùy chọn Server Identifier. Máy khách PHẢI bao hàm tùy chọn Client Identi f i e r để tự định danh nó với máy chủ. Máy khách bao hàm các tùy chọn chứa các I A cho các địa chỉ nó sắp từ chối trong trường “options”. Các địa chỉ cần từ chối PHẢI được bao hàm trong các IA. Các địa chỉ bất kỳ cho các IA mà máy khách muốn tiếp tục sử dụng không được thêm vào các IA. Máy khách KH Ô NG ĐƯỢC sử dụng bất cứ địa chỉ sắp từ chối làm địa chỉ nguồn trong bản tin Decline hoặc trong bản tin phát sau đó bất kỳ. Máy khách phát lại bản tin theo Điều 14, sử dụng các tham số sau: IRT DEC_TIMEOUT MRT 0 MRC DEC_MAX_RC MRD 0 Nếu các địa chỉ bị từ ch ố i nhưng bản tin Reply từ máy chủ DHCP bị mất, máy khách sẽ phát lại bản tin Decline và máy chủ phản hồi bằng bản tin Rep l y chỉ ra trạng thái NoBinding. Như vậy, máy khách không xử l ý bản tin Reply với trạng thái NoBinding trong khi trao đổi bản tin Decline nếu nó có lỗi. 18.1.8. Nhận các bản tin Reply Khi nhận được bản tin Reply phù hợp đáp ứng cho bản tin Solicit (với tùy chọn Rapid Commit), Request, Confirm, Renew, Rebind hoặc Information-request, máy khách sẽ trích thông tin cấu hình chứa trong bản tin Reply. Máy khách CÓ THỂ chọn báo cáo mã trạng thái hoặc bản tin bất kỳ từ tùy chọn Status Code trong bản tin Reply. Máy khách NÊN thực hiện việc phát hiện trùng địa chỉ trên mỗi địa chỉ trong IA bất kỳ mà nó nhận trong bản tin Reply trước khi sử dụng địa chỉ này để truyền lưu lượng. Nếu địa chỉ bất k ỳ được xác định có thể sử dụng trong liên kết, máy khách sẽ gửi bản tin Decline cho máy chủ như mô tả trong Điều 18.1.7. Nếu nhận được bản tin Reply đáp ứng cho bản tin Solicit (với tùy chọn Rapid Commit), Request, Renew hoặc Rebind, máy khách sẽ cập nhật thông tin mà nó đã ghi lại về các IA từ các tùy chọn IA trong bản tin Rep l y: - Ghi lại các thời điểm T1 và T2. - Thêm các địa chỉ mới bất kỳ trong tùy chọn IA vào các IA được máy khách ghi lại. - Cập nhật thời gian tồn tại cho các địa chỉ bất kỳ trong tùy chọn IA mà máy khách đã ghi lại trong IA. - Hủy các địa chỉ bất kỳ từ IA, được ghi lại b ở i máy khách, có thời gian tồn tại bằng 0 trong tùy chọn IA A ddress. - Giữ thông tin không đ ổ i về các địa chỉ mà máy khách đã ghi lại trong IA nhưng không được bao hàm trong các IA từ máy chủ. Việc qu ả n l ý thông tin cấu hình cụ thể được l àm rõ trong định nghĩa của mỗi tùy chọn trong Điều 22. Nếu máy khách nhận được bản tin Reply với mã trạng thái chứa UnspecFail, máy chủ đang chỉ ra rằng nó không thể tiếp tục bản tin do một điều kiện lỗi chưa xác định. Nếu máy khách phát lại bản tin ban đầu tới cùng một máy chủ để cố gắng thực hiện hoạt động mong muốn, thì máy khách PHẢi giới hạn tốc độ phát lại bản tin của nó và giới hạn khoảng thời gian mà nó phát lại bản tin. Khi máy khách nhận được bản tin Reply với tùy chọn Status Code có giá trị UseMulticast, máy khách ghi lại việc nhận bản tin và gửi các bản tin tiếp theo đến máy chủ qua giao diện mà bản tin được nhận bằng cách sử dụng mu l ticast. Máy khách gửi lại bản tin ban đầu sử dụng multicast. Khi máy khách nhận được trạng thái NotOnLink từ máy chủ khi đáp ứng cho bản tin Confirm, thì máy khách thực hiện việc solicittation máy chủ DHCP như mô tả trong Điều 17 và cấu hình khởi tạo từ phía máy khách như được mô tả trong Điều 18. Nếu máy khách nhận được bản tin Reply bất kỳ mà không chỉ ra trạng thái NotOnLink, thì máy khách có thể sử dụng các địa chỉ trong IA và bỏ qua các bản tin bất kỳ chỉ ra trạng thái NotOnLink. Khi máy khách nhận trạng thái NotOnLink từ máy chủ khi đáp ứng với bản tin Request, máy khách có thể làm lại bản tin Request không quy định bất kỳ địa chỉ nào hoặc khởi động lại quá trình khôi phục máy chủ DHCP (xem Điều 17). Máy khách đánh giá m ã trạng thái trong mỗi IA. Nếu mã trạng thái là NoAddrsAvail, thì máy khách chưa nhận các địa chỉ khả dụng trong IA và có thể chọn cách cố gắng lấy địa chỉ cho I A từ một máy chủ khác. Máy khách sử dụng các địa chỉ và thông tin khác từ các IA bất kỳ không chứa tùy chọn Status Cod e có mã NoAddrsAvail. Nếu máy khách không nhận được địa chỉ nào trong các IA bất kỳ, nó có thể cố gắng tiếp cận máy chủ khác (có thể khởi động lại quá trình khám phá máy chủ DHCP) hoặc sử dụng bản tin Information-request để ch ỉ có được thông tin cấu hình. Khi máy khách nhận bản tin Reply đáp ứng cho bản tin Renew hoặc R e bind, máy khách đánh giá mỗi IA một cách độc lập. Với mỗi IA trong bản tin Renew hoặc Rebind ban đầu, máy khách sẽ: - Gửi bản tin Request nếu IA chứa tùy chọn Status Code với trạng thái NoBinding (và không gửi các b ả n tin Renew/Rebind b ổ sung bất kỳ). - Gửi bản tin Renew/Rebind nếu IA không ở trong bản tin Reply. - Nếu không thì chấp nhận thông tin trong IA. Khi máy khách nhận được bản tin Reply đáp ứng với bản tin Release, máy khách xem như sự kiện Release đã hoàn thành, bất kể các tùy chọn Status Code bị máy chủ trả về. Khi máy khách nhận được bản tin Reply còn hiệu lực đáp ứng với bản tin Decline, máy khách sẽ xem như sự kiện Decline đã kết thúc bất kể các tùy chọn Status Code bị máy chủ trả về. 18.2. Hành vi của máy chủ Trường hợp này, máy chủ được giả thiết cấu hình theo cách cụ thể cho các máy khách. Trong hầu hết các trường hợp, máy chủ đáp ứng với bản tin của máy khách. Bản tin Reply PHẢI chứa tùy chọn Server Identifier gồm DU I D của máy chủ và lựa chọn Client Identi f ier từ bản tin của m á y khách nếu có nó. Trong hầu hết các bản tin Reply, máy chủ bao hàm các tùy chọn chứa thông tin cấu hình cho máy khách. Máy chủ PHẢ I nhận thức về các khuyến nghị liên quan đến k í ch thước gói và sử dụng phân mảnh trong Điều 5 của TCVN 9802-1:2013. N ế u máy khách đã bao hàm một tùy chọn Option Request theo bản t i n của nó, máy chủ bao hàm các tùy chọn trong bản tin Reply chứa các thông số cấu hình cho tất cả các tùy chọn được quy định trong tùy chọn Option Request để các máy chủ được cấu hình option để thực hi ệ n chứng nhận trước khi g ử i t ớ i máy khách. Nếu máy chủ được cấu hình để CÓ THỂ trả lại các tùy chọn bổ sung thì máy chủ CÓ TH Ể tr ả lại các tùy chọn bổ sung tới máy khách. 18.2.1. Nhận các bản tin Request Khi máy chủ nhận bản tin Request qua unicast từ máy khách mà máy chủ chưa gửi tùy chọn unicast, th ì máy chủ hủy bản tin Requ e st và phản hồi bằng bản tin Reply chứa tùy chọn Status C ode với giá trị UseMulticast, tùy chọn Server Identifier chứa DUID của máy chủ, tùy chọn Client Identifier từ bản tin của máy khách và không còn tùy chọn nào khác. Khi máy chủ nhận bản tin Request phù hợp, máy chủ tạo ra các gắn kết (bindings) cho máy khách này theo chính sách của máy chủ và thông tin cấu hình và ghi lại cho IA và các thông tin khác được máy khách yêu cầu. Máy chủ xây dựng bản tin Reply bằng cách thiết lập trường “msg-type” về REPLY và sao chép Transaction ID từ bản tin Request vào trường transaction-id. Máy chủ PH Ả I bao hàm tùy chọn Server Identifier chứa DUID của máy chủ và tùy chọn Client Identifier từ bản tin Request trong b ả n tin Reply. Nếu máy chủ xác định rằng tiền tố của một hoặc nhiều địa chỉ IP trong IA bất kỳ trong bản tin từ máy khách không phù hợp với liên kết mà máy khách đang nối tới, thì máy chủ PHẢI trả IA cho máy khách với tùy chọn Status Code cùng với giá trị NotOnLink. Nếu máy chủ không thể ấn định địa chỉ nào cho IA trong bản tin từ máy khách thì máy chủ PHẢI bao hàm IA trong bản tin Reply không kèm địa chỉ trong IA và tùy chọn Status Code trong IA chứa mã trạng thái NoAddrsAvail. Với các IA bất kỳ mà máy chủ có thể ấn định địa chỉ cho nó thì máy chủ bao hàm IA cùng với các địa chỉ và thông số cấu hình khác và ghi IA lại như là một binding máy khách mới. Máy chủ bao hàm tùy chọn Recon fi gure Accept nếu máy chủ muốn yêu cầu máy khách chấp nhận bản tin Reconfigure. Máy chủ bao hàm các tùy chọn khác chứa thông tin cấu hình cần được trả về cho máy khách như mô tả trong Điều 18.2. Nếu máy chủ xác định rằng máy khách đã bao hàm IA trong bản tin Request mà máy chủ đã có một binding để kết hợp IA với máy khách, thì máy khách gửi lại bản tin Request theo đó nó không nhận được bản tin Reply. Máy chủ gửi lại bản tin Reply đã được lưu đệm trước đó hoặc gửi bản tin Reply mới. 18.2.2. Nhận các bản tin Confirm Khi máy chủ nhận bản tin Confirm, máy chủ xác định liệu các đ ị a chỉ trong bản tin Confirm có phù hợp với liên kết mà máy khách nối đến ha y không. Nếu tất cả các địa chỉ trong bản tin Confirm qua được phép thử này, th ì m á y ch ủ tr ả về trạng thái Success. Nếu bất kỳ địa chỉ nào không qua được phép thử này th ì máy chủ trả v ề trạng thái NotOnLink. Nếu máy chủ không thể thực hiện được phép th ử n à y (ví dụ, máy chủ không có thông tin về những tiền tố trên liên kết mà máy khách nối tới), hoặc không c ó địa chỉ nào trong bất kỳ IA nào của các IA được máy khách gửi, th ì máy chủ không được gửi bản tin Reply cho máy kh á ch. Máy chủ b ỏ qua các trường T1 và T2 trong các tùy chọn IA và các trường thời gian tồn tại trong các tùy chọn IA Addr e ss. Máy chủ xây dựng bản tin Reply bằng cách thiết lập trường “msg-type” trong REPLY và sao chép Transaction ID từ bản tin Confirm vào trường transaction-id. Máy chủ PH Ả I bao hàm tùy chọn Server Identifier chứa DUID của máy chủ và tùy chọn Client Identifier từ bản tin Confirm trong bản tin Reply. Máy chủ bao hàm tùy chọn Status Code chỉ ra trạng thái của bản tin Confirm. 18.2.3. Nhận các bản tin Renew Khi máy chủ nhận bản tin Renew qua unicast từ máy khách mà máy chủ chưa gửi tùy chọn Unicast, thì máy chủ bỏ qua bản tin Renew và phản hồi bằng bản tin Reply chứa một tùy chọn Status Code (status code) có giá trị UseMulticast, tùy chọn Server identifier chứa DUID của máy chủ, tùy chọn Client Identifier từ bản tin máy khách và không có tùy chọn nào khác. Khi máy chủ nhận được một bản tin Renew chứa tùy chọn IA từ máy khách, thì nó định vị binding của máy khách và kiểm tra thông tin trong IA từ phía máy khách đảm bảo phù hợp với thông tin đang được lưu cho máy khách đó. Nếu máy chủ không thể tìm thấy thông tin máy khách cho IA th ì máy chủ trả về IA không chứa địa chỉ với tùy chọn Status Co d e được thiết lập là NoBinding trong bản tin Reply. Nếu máy chủ tìm được địa chỉ bất kỳ không phù hợp với liên kết mà máy khách kết nối vào, thì máy chủ trả về địa chỉ máy khách với thời gian tồn tại bằng 0. Nếu máy chủ tìm thấy các địa chỉ trong IA cho máy khách thì máy chủ gửi lại IA cho máy khách với thời gian tồn tại mới và T1/T2 lần. Máy chủ có thể chọn để thay đổ i danh sách các địa chỉ và thời gian tồn t ạ i của các địa chỉ trong IA được trả về cho máy khách. Máy chủ xây dựng bản tin Reply bằng cách thiết lập trường “msg-type” thành REPLY và sao chép Transaction ID từ bản tin Renew vào trường transaction-id. Máy chủ PHẢI bao gồm tùy chọn Server Identifier chứa DUID của máy chủ và tùy chọn Client Identifier từ bản tin Renew trong bản tin Reply. Máy chủ bao gồm các tùy chọn khác chứa thông tin cấu hình cần được tr ả về cho máy khách như mô tả trong 18.2. 18.2.4. Nhận các bản tin Rebind Khi máy chủ nhận bản tin Rebind chứa tùy chọn IA từ máy khách, nó định vị liên kết của máy khách và kiểm tra thông tin trong IA từ máy khách đảm bảo phù hợp với thông tin đang được lưu trữ về máy khách đó. Nếu máy chủ không thể tìm thấy thông tin cho IA và máy chủ xác định rằng các địa chỉ trong IA không phù hợp với liên kết mà giao diện của máy khách nối tới theo thông tin cấu hình đã có của máy chủ, thì máy chủ CÓ THỂ g ửi bản tin Reply tới máy khách kèm IA của máy khách, với thời gian tồn tại của các địa chỉ trong IA thi ế t lập bằng 0. Bản tin Reply này kèm theo th ô ng báo với máy khách rằng các địa chỉ trong IA không còn hiệu lự c. Trong trường hợp này, nếu máy chủ không gửi bản tin Reply, nó sẽ tự động hủy bản tin Rebind. Nếu máy chủ tìm được địa chỉ bất kỳ không phù hợp với liên kết mà máy khách kết nối vào, thì máy chủ trả về địa chỉ máy khách với thời gian tồn tại bằng 0. N ế u máy chủ tìm thấy các địa chỉ trong IA cho máy khách thì máy chủ NÊN gửi lại IA cho máy khách với thời gian tồn tại mới và T1/T2 lần. Máy chủ xây dựng bản tin Reply bằng cách thiết l ập trường “msg-type” thành REP L Y và sao chép Transaction ID từ bản tin Rebind vào trư ờ ng transaction-id. Máy chủ PHẢI bao gồm tùy chọn Server I d enti f ier chứa DUID của máy chủ và tùy chọn Client Identifier từ bản tin Renew trong bản tin Reply. Máy chủ bao gồm các tùy chọn khác chứa thông tin cấu hình cần được tr ả về cho máy khách như mô tả trong 18.2. 18.2.5. Nhận các bản tin Information-request Khi máy chủ nhận bản tin Information-request, thì máy khách yêu cầu thông tin cấu hình m à không cần ấn định địa chỉ nào. Máy chủ xác định tất cả các tham s ố phù hợp cho máy khách, dựa trên các chính sách cấu hình đã biết đối với máy chủ. Máy chủ xây d ự ng bản tin Rep l y bằng cách thiết lập trường “msg-type” thành REPLY và sao chép Transaction ID từ bản tin Information-request vào trường transaction-id. Máy chủ PHẢI bao gồm tùy chọn Server Identifier chứa DUID của máy chủ trong bản tin Reply. Nếu máy khách bao gồm tùy chọn Client Identi f ication trong bản tin Information-request thì máy chủ sao chép tùy chọn này vào bản tin Reply. Máy chủ bao gồm các tùy chọn chứa thông tin cấu hình cần được trả về cho máy khách như mô tả trong 18.2. Trong bản tin Information-request nhận được từ máy khách không bao gồm tùy chọn Client Identifier, thì máy chủ NÊN phản hồi bằng bản tin Reply ch ứ a các thông số cấu hình bất kỳ không được xác định bởi định danh của máy khách. Nếu máy chủ chọn cách không tr ả lời th ì máy khách có thể tiếp tục phát lại bản tin Information-request vô thời hạn. 18.2.6. Nhận các bản tin Release Khi máy chủ nhận bản tin Release qua địa chỉ unicast từ máy khách mà máy chủ chưa từng gửi tùy chọn unicast này th ì máy chủ hủy bản tin Release và phản hồi bằng bản tin Reply chứa tùy chọn Status Code với giá trị UseMulticast, tùy chọn Server Identifier chứa DUID của máy chủ, tùy chọn Client Identifier từ bản tin của máy khách và không còn tùy chọn nào khác. Sau khi nhận bản tin Release phù hợp, máy chủ kiểm tra tính hiệu lực của các IA và địa chỉ trong các IA. Nếu các IA trong bản tin ở trong một binding cho máy khách và các địa chỉ được ấn định bởi máy chủ cho các IA này th ì máy chủ xóa các địa chỉ từ IA và sử dụng để sẵn sàng ấn định cho các máy khách khác. Máy chủ b ỏ qua các địa chỉ không được ấn định cho IA, mặc dù chúng có thể chọn để ghi lỗi. Sau khi tất cả các địa chỉ đã được xử lý, máy chủ tạo ra bản tin Reply và bao gồm tùy chọn Status Code với gi á trị Success, tùy chọn Server Identifier với DUID của máy chủ, tùy chọn Client Identifier với DUID của máy khách. Với mỗi IA trong bản tin Release mà máy chủ không có thông tin binding, thì máy chủ thêm vào 1 tùy chọn IA sử dụng IAID từ bản tin Release và kèm theo tùy chọn Status Code với giá trị NoBinding trong tùy chọn IA. Không có thêm tùy chọn nào khác trong tùy chọn IA. Máy chủ có thể chọn để giữ lại một bản ghi các địa chỉ đã ấn định và các IA sau khi thời gian tồn tại trên địa chỉ đã hết để cho phép máy chủ có thể ấn định lại các địa chỉ này cho máy khách. 18.2.7. Nhận các bản tin Decline Khi máy chủ nhận bản tin Decline qua unicast từ má y khách mà máy chủ chưa từng gửi tùy chọn unicast thì máy chủ hủy bản tin Dec l ine và phản hồi bằng bản tin Reply chứa tùy chọn Status Code với giá trị UseMulticast, tùy chọn Server Identifier chứa DUID của máy chủ, tùy chọn Client Identifier từ bản tin của máy khách và không còn tùy chọn nào khác. Sau khi nhận bản tin Decline phù hợp, má y chủ kiểm tra tính hiệu lực của các IA và địa chỉ trong các IA. Nếu các IA trong bản tin ở trong liên kết với máy khách và các địa chỉ được ấn định bởi máy chủ cho các IA này thì máy chủ xóa các địa chỉ từ IA. Máy chủ b ỏ qua các địa chỉ không được ấn định cho IA (mặc dù chúng có thể chọn để ghi lỗi nếu nó tìm thấy các địa chỉ này). Máy khách tìm thấy địa chỉ bất kỳ trong các bản tin Decline để sẵn sàng sử dụng trên liên kết của nó. Như vậy, máy chủ NÊN đánh dấu các địa chỉ bị từ chối bởi máy khách để các địa chỉ này không được ấn định cho các máy khách khác và CÓ THỂ chọn để thông báo rằng các địa chỉ này đã bị từ chối. Chính sách trên máy chủ xác định khi các địa chỉ trong bản tin Decline có thể sẵn sàng cho việc ấn định mới. Sau khi tất cả các địa chỉ đ ã được xử lý, máy chủ tạo ra bản tin Reply và bao gồm tùy chọn Status Code với giá trị Success, tùy ch ọ n Server Identifier với DUID của máy chủ, tùy chọn Client Identifier với DUID của máy khách. Với mỗi IA trong bản tin Decline mà máy chủ không có thông tin liên kết, thì máy chủ thêm vào 1 tùy chọn IA sử dụng IAID từ bản tin Release và kèm theo tùy chọn Status Code với giá trị NoBinding trong tùy chọn IA. Không có thêm tùy chọn n à o khác trong tùy chọn IA. 18.2.8. Truyền các bản tin Reply Nếu bản tin ban đầu được nhận trực tiếp bởi máy chủ th ì máy chủ sẽ phát bản tin Reply trực tiếp đến máy khách sử dụng đ ị a chỉ trong trường địa chỉ nguồn từ giản đồ IP nơi nhận bản tin ban đầu. Bản tin Reply PHẢI là unicast qua giao diện nơi nhận bản tin ban đầu. Nếu bản tin ban đầu được nhận trong bản tin ReIay-forward thì máy chủ tạo một bản tin Relay- reply với bản tin Reply trong phần t ả i của tùy chọn bản tin Reply (xem 22.10). Nếu các bản tin Rel a y-forward bao g ồ m tùy chọn lnterface- i d thì máy chủ sao ch é p tùy chọn này vào bản tin Relay- reply. Máy chủ gửi unicasts b ả n tin Relay-reply trực tiếp đến nút mạng trung gian sử dụng địa chỉ trong trường địa chỉ nguồn từ giản đồ IP nơi nhận bản tin Relay-forward. 19. Trao đổi cấu hình khởi tạo từ máy chủ DHCP Máy chủ khởi tạo việc trao đổi cấu hình để các máy khách DHCP thu được các địa chỉ mới và thông tin cấu hình khác. Ví dụ, người quản trị có thể sử dụng cách trao đổi cấu hình khởi tạo từ phía máy chủ khi các liên kết trong miền DHCP sắp bị đánh số lại. Các v í dụ khác bao gồm sự thay đổi vị trí của các máy chủ thư mục, thêm các dịch vụ mới như in ấn và sự sẵn sàng của phần mềm mới. 19.1. Hành vi của máy chủ (Server Behavior) Máy chủ gửi bản tin Reconfigure để máy khách khởi tạo ngay việc trao đổi bản tin Renew/Reply hay bản tin Information-request/Reply với máy chủ. 19.1.1. Tạo và truyền các bản tin Recon f igure Máy chủ thiết lập trường “msg-type” thành RECONFIGURE. Máy chủ thiết lập trường transaction-id thành 0. Máy chủ bao gồm tùy chọn Server Identifier có DUID của nó, tùy chọn Client Identifier có DUID của nó trong bản tin Reconfigure. Máy chủ CÓ THỂ bao gồm tùy chọn Option Request (option request) để thông báo cho máy khách thông tin nào đã bị thay đổi hoặc thông tin mới đã được thêm vào. Cụ thể, máy chủ xác định tùy chọn IA trong tùy chọn Option Request nếu máy chủ muốn máy khách nhận thông tin địa chỉ mới. Nếu máy chủ xác định tùy chọn IA trong tùy chọn Option Request thì máy chủ PHẢI bao gồm tùy chọn IA không chứa tùy chọn con nào khác để khẳng định mỗi IA cần được cấu hình lại trên máy khách này. Do nguy cơ tấn công từ chối dịch vụ vào các máy khách DHCP, việc sử dụng cơ ch ế b ả o mật là bắt buộc trong các bản tin Reconfigure. Máy chủ PHẢI sử dụng xác thực DHCP trong bản tin Reconfigure. Máy chủ PHẢI bao gồm tùy chọn bản tin Reconfigure (xác định trong 22.19) để lựa chọn xem máy khách phản hồi với bản tin Renew hay bản tin Information-request. Máy chủ KHÔNG ĐƯỢC bao gồm tùy chọn khách bất kỳ trong bản tin Recon f igure trừ trường hợp đặt biệt được cho phép trong phần định nghĩa của các tùy chọn riêng. Máy chủ gửi mỗi bản tin Reconfigure đến máy khách DHCP, sử dụng địa chỉ một đường IPv6 với phạm vi đủ thuộc về máy khách DHCP. Nếu máy chủ không có địa chỉ mà nó s ử dụng để gửi trực tiếp bản tin Reconfigure đến máy khách thì máy chủ sử dụng bản tin Relay-reply (như mô tả trong 20.3) đ ể gửi bản tin Reconf i gure đến nút mạng trung gian là đối tượng sẽ chuyển tiếp bản tin đến máy khách. Máy chủ có thể thu được địa chỉ máy khách (và nút mạng trung gian phù hợp, nếu cần) qua thông tin máy chủ có về các máy khách liên lạc với máy chủ hoặc qua một số agent bên ngoài. Để cấu hình lại nhiều máy khách, máy chủ phát một đường một bản tin riêng rẽ tới từng máy khách. Máy chủ có thể khởi tạo việc cấu hình lại nhiều máy khách đồng thời; ví dụ, máy chủ có thể gửi bản tin Reconfigure tới các máy khách phụ trong khi việc trao đổi các bản tin Reconfigure trước đó vẫn đang được thực hiện. Bản tin Reconfigure giúp máy khách khởi tạo việc trao đổi bản tin Renew/trả lời hoặc yêu cầu thông tin/trả lời với máy chủ. Máy chủ biên dịch bản tin Renew hoặc yêu cầu thông tin nhận được (cái nào đi xác định trong b ả n tin Rec o n f igure ban đầu) từ máy khách để đáp ứng yêu cầu bản tin Reconfigure. 19.1.2. Quá thời gian và truyền lại các bản tin Reconfigure Nếu máy chủ không nhận được bản tin Renew hoặc cấu hình lại từ máy khách trong REC_TIMEOUT milliseconds, thì máy chủ gửi phát lại bản tin Reconfi g ure, nhân đôi thời gian REC_TIMEOUT và lại đợi. Máy chủ tiếp tục quá trình này cho đến khi các cố g ắ ng REC_MAX_RC không thành công, khi đó máy chủ NÊN b ỏ qua quá trình cấu hình lại cho máy khách. Các giá tr ị ban đầu và mặc định cho REC_TIMEOUT và REC_MAX_RC được cho trong 5.5. 19.2. Nhận các bản tin Renew Máy chủ tạo và gửi bản tin Reply đến máy khách như mô tả trong 8.2.3 và 18.2.8, bao gồm các tùy chọn thông số cấu hình. Máy chủ CÓ THỂ bao gồm các tùy chọn ch ứ a các IA và các giá trị mới cho các thông số cấu hình khác trong bản tin Reply, ngay cả khi các IA và các thông số này không được yêu cầu trong bản tin Renew từ máy khách. 19.3. Nhận các bản tin Information-request Máy chủ tạo và gửi bản tin Reply đến máy khách như mô tả trong 18.2.5 và 18.2.8, bao gồm các tùy chọn thông số cấu hình. Máy chủ CÓ THỂ bao gồm các tùy chọn chứa các giá trị mới cho các thông số cấu hình khác trong b ả n tin Reply, ngay cả khi các thông số này không được yêu cầu trong bản tin Information-request từ máy khách. 19.4. Hành vi của máy khách Máy khách nhận các bản tin Reconfigure được gửi đến cổng 546 UDP trên các giao diện mà nó có thông tin cầu hình qua DHCP. Các bản tin này có thể được gửi ở thời điểm bất kỳ. Do kết quả của việc cấu hình lại có thể ảnh hưởng đến các chương trình lớp ứng dụng, nên máy khách N Ê N lưu lại các sự kiện này và CÓ THỂ cảnh báo các chương trình này về sự thay đổi thông qua giao diện tri ể n khai cụ thể. 19.4.1. Nhận các bản tin Reconfigure Sau khi nhận bản tin Reconfigure phù hợp, máy khách phản hồi bằng bản tin Renew hoặc bản tin Information-request như chỉ ra bởi tùy chọn bản tin Reconfigure (như quy định trong 22.19). Máy khách b ỏ qua trường transaction-id trong bản tin Reconfigure nhận được. Trong khi việc giao dịch đang diễn ra, máy khách tự động hủy bất kỳ các bản tin Reconfigure nào mà nó nhận được. 19.4.2. Tạo và truyền các bản tin Renew Khi phản hồi đối với bản tin Reconfigure, máy khách tạo và gửi bản tin Renew một cách chính xác như m ô t ả trong 18.1.3, với ngoại lệ là máy khách sao chép tùy chọn Option Request và các tùy chọn IA b ấ t kỳ từ bản tin Reconfigure vào bản tin Renew. 19.4.3. Tạo và truyền các bản tin Information-request Khi phản hồi đối với bản tin Reconfigure, máy khách tạo và gửi bản tin In f onmation-request một cách chính xác như trong 18.1.5 với ngoại lệ là máy khách bao gồm tùy chọn Server Identifier với biến số từ bản tin Reconfigure mà máy khách phản hồi. 19.4.4. Quá thời gian và truyền lại các bản tin Renew hoặc y ê u cầu thông tin Máy khách sử dụng biến giống nhau và thuật toán phát lại như trong các bản tin Renew và yêu cầu thông tin được tạo ra khi một phần bị sao đó. Nếu máy khách không nhận hoạt đáp ứ ng với máy chủ ở đoạn cuối. Nếu máy khách không thể nhận được đáp ứng từ máy chủ. Nếu máy khách không nhận phản hồi từ máy chủ trước khi k ế t thúc quá trình di chuyển, máy khách sẽ bỏ qua và hủy các bản in cấu hình lại. 19.4.5. Nhận các bản tin Reply Khi nhận được bản tin Reply còn hiệu lực, thì máy khách xử lý các tùy chọn và thiết lập (hoặc khởi tạo lại) các tham số cấu hình một cách phù hợp. Máy khách ghi lại và cập nhật thời gian tồn tại đối với các địa chỉ bất kỳ xác định trong các IA trong bản tin Reply. 20. Hành vi của nút mạng trung gian Nút mạng trung gian CÓ THỂ được cấu hình sử dụng một danh sách các địa chỉ đích, các địa chỉ này CÓ TH Ể bao gồm các địa chỉ một đường (unicast), địa chỉ đa đường AII_DHCP_Servers hoặc các địa chỉ khác được chọn bởi người quản trị. Nếu nút mạng trung gian này không được cấu hình rõ ràng, n ó PHẢI sử dụng địa chỉ đa đường AII_DHCP_Servers làm giá trị mặc định. Nếu nút mạng trung gian thực hiện chuyển tiếp các bản tin đến địa chỉ đa đường AII_DHCP_Servers hoặc các địa chỉ đa đường khác, nó sẽ thiết lập trường Hop Limit thành 32. 20.1. Chuyển một bản tin của máy khách hoặc bản tin Relay-forward Nút mạng trung gian thực hiện chuyển tiếp cả các bản tin từ các máy khách và các bản tin Relay- forward từ các nút mạng trung gian khác. Nếu một agent nhận được một bản tin hiệu lực để thực hiện chuyển tiếp thì nó xây dựng một bản tin Relay-forward mới. Nút mạng trung gian sao chép địa chỉ nguồn từ phần mào đầu của giản đồ IP trong bản tin nhận được vào trường peer-address của bản tin Relay- forward. Nút mạng trung gian sao chép bản tin DHCP nhận được (trừ các phần mào đầu IP hay UDP) vào tùy ch ọ n bản tin Relay trong bản tin mới. Nút mạng trung gian thêm vào bản tin Relay-forward bất cứ tùy chọn nào khác mà nó được cấu hình để bao gồm. 20.1.1. Chuyển bản tin từ máy khách Nếu nút mạng trung gian nhận được bản tin cần chuyển tiếp từ một máy khách, nút mạng trung gian đặt 1 địa chỉ chung với tiền t ố (prefix) được ấn định cho liên kết mà máy khách cần được ấn định địa chỉ trong trường link-address. Địa chỉ này sẽ được sử dụng bởi máy chủ để xác định liên kết mà từ đó máy khách cần được ấn định địa chỉ và thông tin cấu hình khác. Giá trị hop-count trong bản tin Relay-forward được thiết lập thành 0. Nếu nút mạng trung gian không thể sử dụng địa chỉ trong trường link-address để xác định giao diện mà đáp ứ ng tới máy khách sẽ được chuy ể n tiếp qua nó, thì nút mạng trung gian PHẢI bao gồm tùy chọn lnterface-id ( xem 22.18) trong bản tin Relay-forward. Máy chủ sẽ bao gồm lựa chọn lnterface-id trong bản tin Relay-reply của nó. Nút mạng trung gian điền đầy trường link-address như mô tả trong đoạn trước bất kể việc nút mạng trung gian có trong bản tin Re l ay-forward. 20.1.2. Chuyển bản tin từ nút mạng trung gian Nếu bản tin được nhận bởi nút mạng trung gian l à một bản tin Relay-forward và giá trị hop-count trong bản tin không lớn hơn hoặc bằng HOP_COUNT_LIMIT, thì nút mạng trung gian xóa bản tin nhận được. Nút mạng trung gian sao chép địa chỉ nguồn từ giản đồ IP trong bản tin nhận được từ máy khách vào trường peer-address trong bản tin Relay-forward và thiết lập trường hop-count thành giá trị của trường hop-count trong bản tin đã nhận được cộng thêm 1. Nếu địa chỉ nguồn từ phần mào đầu của gi ả n đồ IP trong bản tin nhận được l à địa chỉ toàn cục hoặc cục bộ (và thiết bị mà nút mạng trung gian đang chạy chỉ thuộc về 1 khu vực), nút mạng trung gian thiết lập trường link-address thành 0; hay cách khác nút mạng trung gian thiết lập trường link-address thành địa chỉ toàn cục hoặc cục bộ được ấn định cho giao diện mà bản tin được nhận, hoặc bao gồm tùy ch ọ n lnterface-id để xác định giao diện mà bản tin được nhận. 20.2. Chuy ể n một bản tin Relay-reply Nút mạng trung gian xử lý các tùy chọn bất kỳ trong bản tin Relay-reply cùng với tùy chọn bản tin Relay và sau đó hủy các tùy chọn này. Nút mạng trung gian trích xuất bản tin từ tùy chọn bản tin Relay và thực hiện chuyển tiếp nó đến địa chỉ chứa trong trường peer-address của bản tin Relay-reply. Nếu bản tin Relay-reply bao gồm tùy chọn lnterface-id, nút mạng trung gian thực hiện chuyển tiếp bản tin từ máy chủ đ ế n máy khách trên đường liên kết được xác định bởi tùy chọn lnterface-id option. Nói cách khác, nếu trường link-address không thiết lập bằng 0 thì nút mạng trung gian thực hiện chuyển tiếp bản tin trên đường liên kết được xác định bởi trường link-address. 20.3. Cấu trúc bản tin Relay-reply Máy chủ sử dụng bản tin Relay-reply đ ể trả về phản hồi cho máy khách nếu bản tin ban đầu từ máy khách được chuyển tiếp tới máy chủ trong bản tin Relay-forward hoặc đ ể gửi bản tin Reconfigure đến máy khách nếu máy chủ không có địa chỉ có thể sử dụng để gửi bản tin trực tiếp đến máy khách. Phản hồi đối với máy khách PHẢI b ị chuyển tiếp qua cùng các nút mạng trung gian như bản tin máy khách ban đầu. Máy chủ tạo ra điều này bằng cách tạo bản tin Relay-reply trong đó bao gồm tùy chọn bản tin chuyển tiếp chứa bản tin cho nút mạng trung gian tiếp theo trong đường tr ở về máy khách. Bản tin Relay-reply chứa tùy chọn bản tin chuyển tiếp khác để gửi tới nút mạng trung gian tiếp theo và cứ như thế. Máy chủ PHẢI ghi lại nội dung của các trường peer-address trong bản tin nhận được sao cho nó có thể xây dựng bản tin Relay-reply phù hợp mang theo phản hồi từ máy chủ. V í dụ, nếu máy khách C gửi b ả n tin b ị chuyển tiếp bởi nút mạng trung gian A đến nút mạng trung gian B và sau đó đến máy chủ, thì máy chủ cần như bản tin chuyển tiếp tr ả l ờ i đ ế n nút mạng trung gian B như sau: msg-type: RELAY-REPLY hop-count: 1 link-address: 0 peer-address: A Tùy chọn bản tin chuyển tiếp, chứa: msg-type: RELAY-REPLY hop-count: 0 link-address: địa chỉ từ liên kết mà C được nối tới peer-address: C Tùy chọn bản tin chuyển tiếp: Khi gửi bản tin Reconfigure cho máy khách qua một nút mạng trung gian, máy chủ tạo một bản tin Relay-reply bao gồm tùy chọn bản tin chuy ể n tiếp chứa bản tin Reconfigure cho nút mạng trung gian tiếp theo trong đường tr ở về tới máy khách. Máy chủ thiết lập trường peer-address trong phần mào đầu bản tin Relay-reply thành địa chỉ của máy kh á ch và thiết l ậ p trường link-address theo yêu cầu của nút mạng trung gian để thực hiện chuyển tiếp bản tin Reconfigure tới máy khách. Máy chủ chứa các địa chỉ của máy khách và nút mạng trung gian qua việc tương tác v ớ i máy khách hoặc qua 1 cơ chế khác. 21. Xác thực các bản tin DHCP M ột số nhà quản trị mạng có thể mong muốn cung cấp khả năng xác thực của nguồn và các nội dung của các bản tin DHCP. V í dụ, các máy khác có thể PHẢI ch ị u sự tấn công t ừ chối dịch vụ do việc sử dụng các máy chủ DHCP giả (bogus) hoặc có thể đơn gi ả n là các máy chủ DHCP vô tình bị cấu hình sai. Các nhà quản trị mạng có thể muốn cưỡng ép việc ấn định các địa chỉ cho các host được quản lý để tránh việc tấn công từ chối d ị ch vụ trong các môi trường “thù đ ị ch” mà các thiết bị mạng không được bảo đ ả m an toàn đủ về mặt vật lý như các mạng vô tuyến hoặc tòa nhà ký túc xá. Cơ chế xác thực DHCP dựa trên việc thiết kế xác thực cho IPv4 [RFC 3118:2001]. 21.1. Bảo mật các bản tin gửi giữa các máy chủ và các nút mạng trung gian Các nút mạng trung gian và máy chủ trao đổi các bản tin sử dụng các cơ chế IPsec cho IPv6. Nếu bản tin máy khách bị chuyển tiếp qua nhiều nút mạng trung gian, mỗi nút mạng trung gian phải được thiết lập độc lập, mối quan hệ tin cậy. Như vậy, nếu các bản tin từ máy khách C sẽ bị chuyển tiếp bởi nút mạng trung gian A tới nút mạng trung gian B và sau đó đến máy chủ, các nút mạng trung gian A và B phải được cấu hình đ ể sử dụng IPsec cho các bản tin chúng trao đổi và nút mạng trung gian B, máy chủ phải được cấu hình để sử dụng IPsec cho các bản tin chung trao đổi. Các nút mạng trung gian và máy chủ để hỗ trợ bảo mật kết nối của nút mạng trung gian với máy chủ hay nút mạng trung gian với nút mạng trung gian thì sử dụng IPsec theo các điều kiện sau đây: Bộ chọn Các địa chỉ của nút mạng trung gian hoặc má y chủ được cấu hình thủ công cho các nút mạng trung gian đ ể chuyển tiếp đi các bản tin DHCP. Mỗi Nút mạng trung gian và máy chủ để có thể sử dụng IPsec bảo mật cho các bản tin DHCP PHẢI được c ấ u hình với danh sách các nút mạng trung gian mà bản tin hồi đáp. Bộ chọn cho các nút mạng trung gian và các máy chủ sẽ ghép cặp các địa chỉ xác định ra các n ú t mạng trung gian và máy chủ mà trao đổi các bản tin DHCP trên các cổng UDP 546 và UDP 547 của DHCPv6. Chế độ sử dụng Các nút mạng trung gian và máy chủ sử dụng ở chế độ truyền tải và ESP. Thông tin trong các bản tin DHCP thường không bị coi là bảo mật, vì vậy có thể không cần mã hóa (có nghĩa là, có thể sử dụng mã NULL). Quản lý khóa Do các nút mạng trung gian và các máy chủ được sử dụng bên trong tổ chức, nên c ó thể không cần mô hình khóa công cộng. Theo đó, IKE với các bí mật cần được nghiên cứu đ ể được hỗ trợ. IKE có các kh óa công cộng có thể được hỗ trợ. Do các nút mạng trung gian v à các máy chủ PHẢI được cấu hình bằng tay, cấu hình quản lý khóa bằng tay, tuy nhiên không hỗ trợ bảo vệ chống lại các bản tin gửi lại. Theo đó, IKE với những bí mật được chia sẻ trước NÊN được hỗ trợ. IKE với khóa công khai CÓ THỂ được hỗ trợ. Chính sách bảo mật Các bản tin DHCP giữa các nút mạng trung gian và máy chủ không chỉ được chấp nhận t ừ các DHCP như xác định trong cấu hình cục bộ. Xác thực Các khóa chia sẻ, sắp xếp các địa chỉ IP của các bản tin DHCP nhận được, là đủ cho ứng dụng này. Tính sẵn sàng Việc triển khai IPsec hợp lý có thể sẵn sàng cho các nút mạng trung gian trong nhiều thiết bị sử dụng trong doanh nghiệp và mạng lõi ISP. IPsec có thể sẵn sàng cho các nút mạng trung gian trong các thiết bị nhỏ sử dụng ở nhà hoặc văn phòng nh ỏ . 21.2. Tóm lược về xác thực DHCP Việc xác thực các bản tin DHCP đạt được nhờ việc sử dụng tùy chọn Authentication (xem 22.11). Thông tin xác thực được thực hiện trong tùy chọn A u thenticati o n có thể được sử dụng đ ể xác định một cách tin cậy về nguồn của bản tin DHCP và để khẳng định rằng nội dung của bản tin DHCP chưa bị làm giả mạo. Tùy chọn Authentication cung cấp khung cho nhiều giao thức xác thực. Hai giao thức này được định nghĩa ở đây. Các giao thức khác trong tương lai sẽ được quy định trong các tiêu chuẩn riêng. Bản tin DHCP bất kỳ KHÔNG ĐƯỢC bao gồm nhiều hơn một tùy chọn Authentication. Trường protocol trong tùy chọn Authentication xác định giao thức cụ thể được sử dụng để tạo ra thông tin xác thực thực hiện trên tùy chọn này. Trường algorithm xác định giao thức cụ th ể trong giao thức xác thực; v í dụ, trường algorithm xác định thuật toán băm (hash) sử dụng để tạo ra mã xác thực bản tin (MAC) trong tùy chọn Authentication. Trường RDM (Phương thức phát hiện sự chạy lại) xác định kiểu phát hiện sự chạy lại được sử dụng trong trường phát hiện sự chạy lại. 21.3. Phát hiện sự chạy lại Trường RDM xác định kiểu phát hiện sự chạy lại sử sử dụng trong trường phát hiện chạy lại. Nếu tr ư ờng RDM chứa 0x00 thì trường phát hiện sự chạy lại PHẢI được thiết lập giá trị đếm tăng đơn điệu. Bằng cách sử dụng giá trị đếm, như là thời gian hiện t ại (v í dụ như một Dấu thời gian (timestamp) của định dạng NTP), có thể giảm nguy hiểm các tấn công chạy lại. Phương thức này PHẢI được tất cả các giao thức hỗ trợ. 21.4. Giao thức xác thực có trễ Nếu trường giao thức là 2, bản tin sử dụng cơ chế “xác thực trễ”. Trong xác thực trễ, máy khách yêu cầu xác thực trong bản tin Solicit và máy chủ tr ả lời bằng bản tin Advertise chứa thông tin xác thực. Thông tin xác thực này chứa giá trị được nguồn tạo ra như là mã xác thực bản tin (MAC) để cung cấp xác thực bản tin và xác thực phần tử. Việc sử dụng kỹ thuật cụ thể dựa trên giao thức HMAC sử dụng hàm băm MD5 được định nghĩa ở đây. 21.4.1. Sử dụng tùy chọn Authentication trong giao thức xác thực có trễ Trong một bản tin Solicit, máy khách điền đầy trong các trường protocol, algorithm và RMD trong tùy chọn Authentication với các tham chiếu của máy khách. Máy khách thiết lập trường replay detection thành 0 và bỏ qua trường thông tin xác thực. Máy khách thiết lập trường option-len thành 11. Trong tất cả các bản tin khác, các trường protocol và algorithm xác định tùy chọn sử dụng để cấu trúc các nội dung của trường thông tin xác thực. Trường RDM xác định tùy chọn sử dụng để cấu trúc các nội dung trường phát hiện sự chạy lại. Định dạng thông tin xác thực như sau: Vùng DHCP Vùng DHCP xác định khóa sử dụng để tạo ra gi á trị HMAC-MD5. ID khóa Biến khóa xác định khóa sử dụng để tạo ra giá trị HMAC-MD5. HMAC-MD5 Mã xác thực bản tin được tạo ra nhờ việc áp dụng MD5 vào bản tin DHCP sử dụng khóa xác định bởi vùng DHCP, DUID của máy khách v à IP khóa. Người gửi t í nh MAC sử dụng thuật toán tạo HMAC và hàm băm MD5. Toàn bộ bản tin DHCP (thiết lập trường MAC của tùy chọn Authentication về 0), bao gồm cả mào đầu bản tin DHCP và trường các tùy chọn, được sử dụng làm đầu vào của hàm tính toán HMAC-MD5. 21.4.2. Hiệu lực của bản tin Bất kỳ bản tin DHCP bao gồm nhiều hơn một tùy chọn authentication đều PHẢI được hủy. Để xác nhận t í nh hợp lệ của bản tin gửi đến, người nhận trước tiên PHẢI kiểm tra giá trị trong trường phát hiện chạy lại (replay detection) căn cứ theo phương thức phát hiện sự chạy lại được quy định trong trường RDM. Sau đó, người nhận tính MAC như mô tả trong. Toàn bộ bản tin DHCP (thiết lập trường MAC trong tùy chọn Authentication thành 0) được sử dụng làm đầu vào hàm tính toán HMAC- MD5. Nếu MAC t í nh được không phù hợp với MAC chứa trong tùy chọn Authentication thì phía nhận PHẢI hủy bản tin DHCP. 21.4.3. Sử dụng khóa Mỗi máy khách DHCP có một bộ khóa. Mỗi khóa được định danh bởi ú c đầu qua một số cơ chế. Thời gian tồn tại của mỗi khóa được phân phối cùng với khóa. Các cơ chế phân phối khóa và đặc điểm thời gian tồn tại nằm ngoài phạm vi của tiêu chuẩn này. Máy khách và máy chủ sử dụng một trong số các khóa để xác thực các bản tin DHCP trong 1 phiên (cho đến khi bản tin Solicit được gửi bởi máy khách). 21.4.4. Các v ấ n đề của máy khách sử dụng giao thức xác thực có trễ Máy khách thông báo dự định sử dụng xác thực DHCP bằng cách thêm tùy chọn Authentication trong bản tin Solicit. Máy chủ lựa chọn một khóa của máy khách dựa trên DUID của máy khách. Máy khách và máy chủ sử dụng khóa này đ ể xác thực tất cả các bản tin DHCP được trao đổi trong phiên. 21.4.4.1. Gửi các bản tin Solicit Khi máy khách gửi một bản tin Solicit và muốn sử dụng sự xác thực, nó sẽ chứa 1 tùy chọn Authentication với giao thức, thuật toán và RDM mong muốn như mô tả trong 21.4. Trong tùy chọn Authentication này sẽ không bao gồm việc phát hiện chạy lại hay thông tin xác thực nào khác. 21.4.4.2. Nhận các bản tin Advertise Máy khách kiểm tr ả sự phù hợp của các bản tin Advertise bất kỳ chứa tùy chọn Authentication quy định giao thức xác thực trễ bằng cách sử dụng phép thử sự phù hợp mô tả trong 21.4.2. Hành vi của máy khách, nếu không có các bản tin Advertise bao hàm thông tin xác thực hay bỏ qua phép thử sự phù hợp, được kiểm soát bởi chính sách cục bộ của chính máy khách. Theo chính sách của máy khách, máy khách CÓ THỂ chọn để phản hồi bản tin Advertise mà chưa được xác thực. Quyết định thiết lập chính sách đ ể chấp nhận các bản tin chưa được xác thực cần được xây dựng thận trọng. Việc chấp nhận bản tin Advertise chưa được xác thực có thể làm cho máy khách tr ở nên dễ bị tổn thương khi bị tấn công. Nếu người dùng cục bộ không được thông báo rõ ràng rằng máy khách đã chấp nhận bản tin Advertise chưa xác thực thì người dùng có thể gi ả thiết là máy khách đã nhận bản tin xác thực và PHẢI chịu sự tấn công qua các bản tin chưa xác thực. Máy khách PHẢI được cấu hình để hủy các bản tin chưa xác thực và NÊN được cấu hình mặc định để hủy các bản tin chưa được xác thực nếu máy khách được cấu hình với khoa xác thực hoặc thông tin xác thực khác. Máy khách CÓ THỂ chọn đ ể phân biệt giữa các bản tin Advertise không có thông tin xác thực và bản tin Advertise không qua phép thử phù hợp; ví dụ, máy khách có thể chấp nhận cái trước và hủy cái sau. Nếu máy khách không chấp nhận bản tin chưa xác thực thì máy khách NÊN thông báo đến các người dùng cục bộ và NÊN lưu lại sự kiện. 21.4.4.3. Gửi các bản tin Request, Confirm, Renew, Rebind, Decline hay Release Nếu máy khách xác thực bản tin Advertise qua cách máy khách lựa chọn máy chủ thì máy khách PHẢI tạo ra thông tin xác thực cho các bản tin Request, Confirm, Renew, Rebind hay Release gửi đến máy chủ, như được mô tả trong 21.4. Khi máy khách gửi bản tin tiếp theo, nó PHẢI sử dụng khóa giống như máy chủ để tạo ra thông tin xác thực. 21.4.4.4. Gửi các bản tin Information-request Nếu máy chủ đã lựa chọn khóa cho máy khách trong lần trao đổi bản tin trước đó (xem 21.4.5.1) th ì máy khách PHẢI sử dụng cùng khóa đó để tạo ra thông tin xác thực trong suốt phiên. 21.4.4.5. Nhận các bản tin Reply Nếu máy khách đã xác thực bản tin Advertise nó chấp nhận, máy khách PHẢI đánh giá phù hợp bản tin Reply kết hợp từ máy chủ. Máy khách PHẢI hủy bản tin Reply nếu bản tin không qua được phép thử phù hợp và CÓ THỂ lưu lại lỗi này. Nếu bản tin Reply không qua được phép thử phù hợp th ì máy khách PHẢI khởi động lại quá trình cấu hình DHCP bằng cách gửi bản tin Solicit. Nếu máy khách chấp nhận bản tin A d vertise mà không bao hàm thông tin xác thực hoặc không qua được phép thử phù hợp thì máy khách CÓ THỂ chấp nhận bản tin Reply chưa được xác thực từ máy chủ. 21.4.4.6. Nhận các bản tin Reconfigure Máy khách PH Ả I hủy bản tin Reconfigure nếu bản tin không qua được phép th ử phù hợp và CÓ TH Ể lưu lỗi này lại. 21.4.5. Các vấn đề của máy chủ sử dụng giao thức xác thực có trễ Sau khi nhận bản tin Solicit có chứa tùy chọn Authentication, máy chủ lựa chọn kh óa cho máy khách dựa tr ê n DUID của máy khách và chính sách lựa chọn khóa theo đó máy chủ đã đư ợc cấu hình. Máy chủ định danh kh ó a được chọn trong bản tin Advertise và sử dụng khoa để kiểm tra sự phù hợp các bản tin tiếp theo giữa máy chủ và máy khách. 21.4.5.1. Nhận các bản tin Solicit và gửi các bản tin Advertise Máy chủ lựa chọn khóa cho máy khách và bao hàm thông tin xác thực trong bản tin Advertise trả cho máy khách như quy định trong 21.4. Máy chủ PHẢI ghi lại định danh của kh ó a được chọn cho máy khách và sử dụng đúng khóa này để đánh giá phù hợp các bản tin tiếp theo với máy khách. 21.4.5.2. Nhận các bản tin Request, Confirm, Renew, Rebind hay Release và gửi các bản tin Reply Máy chủ sử dụng khóa được định danh trong bản tin và đánh giá phù hợp bản tin như quy định trong 21.4.2. Nếu bản tin không qua được phép thử phù hợp hoặc máy chủ không biết khóa được định danh bởi trường ‘ key ID ’ thì máy chủ PHẢI hủy bản tin và CÓ TH Ể chọn cách lưu lại lỗi phù hợp này. Nếu bản tin qua được phép thử phù hợp, máy chủ ph ả n hồi bằng bản tin cụ thể như mô tả trong 18.2. Máy chủ PHẢI bao hàm thông tin xác thực được tạo bằng cách sử dụng khóa được định danh trong bản tin nhận được, như quy định trong 21.4. 21.5. Giao thức xác thực bằng khóa cấu hình lại Giao thức xác thực khóa cấu hình lại cho phép chống lại việc cấu hình sai của máy khách do bản tin Reconfigure được gửi bởi một máy chủ bị nhiễm độc. Trong giao thức này, máy chủ DHCP gửi 1 khóa cấu hình lại cho máy khách trong lần trao đổi các bản tin DHCP ban đầu. Máy khách ghi lại khóa cấu hình lại để sử dụng khi xác thực các bản tin Reconfigure tiếp theo từ máy chủ này, Máy chủ sau đó bao hàm thông số HMAC được tính từ khóa cấu hình lại trong các bản tin Reconfigure tiếp theo. Cả khóa cấu hình lại được gửi từ máy chủ đến máy khách và HMAC trong các bản tin Reconfigure tiếp theo đều được làm thông tin xác thực trong tùy chọn Authentication. Định dạng của thông tin xác thực được định nghĩa trong phần sau. Giao thức khóa cấu hình lại được sử dụng (khởi đầu bởi máy chủ) chỉ khi máy khách và máy chủ không sử dụng giao thức xác thực nào khác và máy khách và máy chủ đã thống nhất để sử dụng các bản tin Reconfigure. 21.5.1. Sử dụng t ù y chọn Authentication trong giao thức xác thực bằng khóa c ấ u hình lại Các trường sau đây được thiết lập trong tùy chọn Authentication cho Giao thức xác thực bằng khóa cấu hình lại: Giao thức (protocol) 3 Thuật toán (algorithm) 1 RDM 0 Định dạng của tùy chọn Authentication cho Giao thức xác thực bằng khóa cấu hình lại là: Kiểu dữ liệu trong trường Value trong tùy chọn này: 1. Giá trị khóa cấu hình lại (được dùng trong bản tin Reply). 2. HMAC-MD5 của bản tin (được dùng trong bản tin Reconfigure). Dữ liệu Value được xác định theo trường. 21.5.2. Các v ấ n đ ề của máy chủ sử dụng giao thức khóa cấu hình lại Máy chủ lựa chọn 1 khóa cấu hình lại cho máy khách trong khi trao đổi bản tin Reques t/ Reply, Solicit/Reply hoặc Information-reques t/ Reply. Máy chủ lưu lại khóa cấu hình lại và truyền phát kh ó a này đến máy khách trong lựa chọn xác thực trong bản tin Reply. Khóa cấu hình lại dài 128 bit và PHẢI là ngẫu nhiên mã hóa mạnh hoặc số giả ngẫu nhiên không dễ dự đoán. Để cung cấp xác thực cho bản tin Recon fi gure, máy chủ lựa chọn giá trị phát hiện chạy lại theo RDM được chọn bởi máy chủ và tính HMAC-MD5 của bản tin Reconfigure sử dụng khóa cấu hình lại của máy khách. Máy chủ tính HMAC-MD5 trong bản tin Reconfigure DHCP; trường HMAC-MD5 trong tùy chọn Authentication được thiết l ập b ằ ng 0 để tính HMAC-MD5. Máy chủ bao hàm HMAC-MD5 trong trường thông tin xác thực trong tùy chọn Authentication bao hàm trong bản tin Reconfigure được gửi đến máy khách. 21.5.3. Các vấn đ ề của máy khách sử dụng giao thức khóa cấu hình lại Máy khách sẽ nhận khóa cấu hình lại từ máy chủ trong bản tin Reply ban đầu từ máy chủ. Máy khách ghi lại khóa cấu hình lại để sử dụng cho việc xác thực các bản tin Reconfigure tiếp theo. Để xác thực một bản tin Reconfigure, máy khách tính HMAC-MD5 trong bản tin Reconfigure DHCP, sử dụng khóa cấu hình l ại nhận được từ máy chủ. Nếu HMAC-MD5 tính được phù hợp với giá trụ trong tùy chọn Authentication thì máy khách chấp nhận bản tin Reconfigure. 22. Các tùy chọn DHCP Các tùy chọn được sử dụng để mang thông tin bổ sung và các thông số trong các bản tin DHCP. Mọi tùy chọn đều có định dạng cơ b ả n chung như mô tả trong 22.1. Tất cả các giá trị trong các tùy chọn này được biểu diễn ở thứ tự byte mạng. Tài liệu n à y mô tả các tùy ch ọ n DHCP được định nghĩa là một phần của tiêu chu ẩ n DHCP cơ sở. Các tùy chọn khác được định nghĩa trong các tài liệu khác. Trừ khi có quy định khác, mỗi tùy chọn có thể ch ỉ xuất hiện trong phần tùy chọn của bản tin DHCP và có thể chỉ xuất hiện 1 lần. Nếu một tùy chọn xuất hiện nhiều lần, mỗi l ầ n được xem xét riêng rẽ và các vùng dữ liệu của các tùy chọn KHÔNG ĐƯỢC nối hay kết hợp với nhau. 22.1. Định dạng của các tùy chọn DHCP Định dạng của các tùy chọn DHCP là: Mã của tùy ch ọ n: s ố nguyên không dấu định danh kiểu tùy chọn thực hiện trong tùy chọn này. option-len: số nguyên không dấu chỉ ra độ dài trư ờ ng option-data trong tùy chọn này, tính bằng octet. option-data: Dữ liệu cho tùy chọn này; định dạng của dữ liệu phụ thuộc định nghĩa tùy chọn. Các tùy chọn DHCPv6 bị giới hạn bởi việc sử dụng đóng gói (encapsulation). Một số tùy chọn thư ờ ng áp dụng đối với máy khách, một số cụ thể đối với IA và một số cụ thể đối với các địa chỉ trong IA. Hai trường hợp sau được nêu trong 22.4 và 22.6. 22.2. Tùy chọn Client ldentification Tùy chọn Client Identi f ication được dùng để mạng một DUID (xem 9) định danh máy khách giữa máy khách và máy chủ. Định dạng của tùy chọn Client Identi f ication như sau: Mã của tùy chọn: OPTION_CLIENTID (1). option-len: Độ dài của DUID, tính bằng octet. DUID: DUID đối với máy khách. 22.3. Tùy chọn Server Identifier Tùy chọn Server Identi fi er được dùng để mang một DUID (xem 9) định danh máy chủ giữa máy khách và máy chủ. Định dạng của tùy chọn Server Identifier như sau: Mã của tùy ch ọ n: OPTION_SERVERID (2). option-len: Độ dài của DUID, t í nh bằng octet. DUID: DUID đối với máy chủ. 22.4. Tùy chọn IA cho địa chỉ lâu dài Tùy chọn I A cho các địa chỉ lâu dài (tùy chọn IA_NA) được sử dụng để mang một IA_NA, các tham số kết hợp với IA_NA và các địa chỉ lâu dài kết hợp với IA_NA. Các địa chỉ xuất hiện trong t ù y chọn I A _NA không phải là các địa chỉ tạm thời (xem 22.5). Định dạng của tùy chọn IA_NA như sau: Mã của tùy chọn: OPTION_IA_NA (3). option-len: 12 + độ dài của trường I A _NA-options IAID Định danh duy nhất cho IA NA này; IAID phải là duy nhất trong số các định danh cho tất cả các IA NA của các máy khách. Không gian số cho các IAID của các IA_NA là riêng rẽ với không gian số cho các IAID của IA_TA. T1 Thời gian mà tại đó máy khách liên lạc với máy chủ từ các địa chỉ mà IA_NA có được để t ằ ng thời gian tồn tại của các địa chỉ đã được ấn định cho IA_NA; T1 là khoảng thời gian tương ứng với thời gian hiện tại tính bằng giây. T2 Thời gian mà tại đó máy khách liên lạc với máy chủ sẵn sàng bất kỳ để tằng thời gian tồn tại của các địa chỉ đ ã ấn định cho IA_NA; T2 là khoảng thời gian tương ứng so với thời gian hiện tại tính bằng giây. IA_NA-options Các tùy chọn kết hợp với IA_NA này. Trường I A _NA đóng gói các tùy chọn này là cụ thể cho IA_NA này. Ví dụ, tất cả các tùy chọn địa chỉ IA mang các địa chỉ kết hợp với IA_NA này đều ở trong trường IA_NA-options. Tùy chọn IA_NA có thể ch ỉ xuất hiện trong vùng tùy chọn của bản tin DHCP. Một bản tin DHCP có thể có nhiều tùy chọn IA_NA. Trạng thái của hoạt động bất kỳ liên quan đến IA_NA này được chỉ ra trong tùy chọn Status Code trong trường IA_NA-options. Chú ý rằng IA_NA không có thời gian tồn tại hay thời gian bỏ rõ ràng của nó. Khi hết thời gian tồn tại của tất cả các địa chỉ trong IA_NA, IA _ NA có thể được xem như hết hiệu lực. T1 và T2 được bao hàm để cho phép máy chủ kiểm soát khi máy khách liên lạc lại máy chủ về một I A_NA cụ thể. Trong bản tin được gửi bởi máy khách đến máy chủ, các giá trị trong các trường T1 và T2 chỉ ra tham chiếu của máy khách đến các thông số này. Máy khách thiết lập T1 và T2 thành 0 nếu nó không tham chiếu các giá trị n à y. Nếu bản tin được gửi bởi máy chủ đến máy khách, máy khách PHẢI sử dụng các giá trị trong các trường T1 và T2 cho các tham số T1 và T2 trừ khi các giá trị trong các trường này là 0. Các giá trị trong T1 và T2 tính là giây cho đến khi T1 và T2. Máy chủ lựa chọn các thời gian T1 và T2 cho phép máy khách tằng thời gian tồn tại của các địa chỉ trong IA_NA trước khi nó quá hạn, ngay cả nếu máy chủ chưa sẵn sàng trong một khoảng thời gian ngắn. Các giá trị khuyến nghị cho T1 và T2 là 0,5 và 0,8 lần thời gian tồn tại ngắn nhất của các địa chỉ trong IA mà máy chủ cho phép tăng. Nếu thời gian ngắn nhất là 0 xffffffff (“in f inity” - vô hạn), thì các giá trị T1 và T2 khuyến nghị cũng là 0 xffffffff. Nếu thời gian mà tại đó các địa chỉ trong IA_NA sắp được làm mới còn lại đối với máy khách thì máy chủ thiết lập T1 và T2 thành 0. Nếu máy chủ nhận được IA_NA có T1 l ớ n hơn T2 và cả T1, T2 đều lớn hơn 0 th ì máy chủ bỏ qua các giá trị không phù hợp của T1 và T2 và xử lý IA_NA như là máy khách có T1 và T2 bằng 0. Nếu máy chủ nhận được IA_NA với T1 lớn hơn T2 và c ả T1 , T2 đều lớn hơn 0 thì máy chủ bỏ qua tùy chọn IA_NA và xử lý phần còn lại của bản tin như là máy chủ không bao hàm tùy chọn IA_NA phù hợp. Lưu ý khi thiết lập T1 hoặc T2 là vô hạn. Máy khách sẽ không bao giờ cố gắng tằng thời gian tồn tại của địa chỉ bất kỳ trong IA với T1 thiết lập là Máy khách sẽ không bao giờ cố sử dụng bản tin Rebind để định vị máy chủ khác để tăng thời gian tồn tại của địa chỉ bất kỳ trong IA v ớ i T2 thiết lập là 0xffffffff. 22.5. Tùy chọn IA cho địa ch ỉ tạm thời Tùy chọn IA cho các địa chỉ tạm thời (tùy chọn IA_TA) được sử dụng đ ể chuyển một IA_TA, các thông số gắn với IA_TA và các địa chỉ liên kết với IA_TA. Máy khách sử dụng tất cả các địa chỉ trong tùy chọn này như các địa chỉ tạm thời. Các địa chỉ này được định nghĩa trong RFC 3041. Định dạng của các tùy chọn IA_TA là: Mã của tùy chọn: là OPTION IA-TA (4) Option len: là 4 + độ dài của trường tùy chọn IA-TA IAID: là định danh duy nhất cho IA-TA này; IAID PH Ả I là duy nhất giữa các định danh cho tất cả các IA_TAs của máy khách, số khoảng trống d à nh cho các IA-TA IAID khác với số khoảng trống dành cho các IA-NA IAID. IA-TA options: là các tùy chọn được gắn với IA-TA này. Trường tùy chọn I A _TA bao gồm các tùy chọn cụ thể cho IA_TA này. Ví dụ, tất cả các tùy chọn của địa chỉ IA chứa trong các địa chỉ liên kết đến IA_TA này nằm trong trường tùy chọn IA_TA. Mỗi IA_TA mang một bộ/ tập hợp các địa chỉ tạm thời, tức là, nhiều nhất là một địa chỉ từ mỗi đoạn đầu được chỉ định cho một liên kết được đính kèm với máy khách. Tùy chọn IA_TA có thể chỉ xuất hiện trong vùng tùy chọn của một bản tin DHCP. Một bản tin DHCP có thể chứa nhiều tùy chọn IA_TA. Trạng thái của mỗi hoạt động liên quan t ớ i IA_TA n à y được chỉ ra trong các tùy chọn Status Code của trường tùy chọn IA_TA. Chú ý rằng, IA không có thời gian tồn tại (lifetime) hay Độ dài thuê (lease length) rõ ràng. Khi thời gian tồn tại hợp lệ của tất cả các địa chỉ trong một IA_TA đã hết hạn, IA có thể được coi như đã hết/ dừng. Một tùy chọn IA_TA không bao gồm giá trị cho T1 và 12. Máy khách CÓ THỂ yêu cầu thời gian tồn tại trên địa chỉ tạm thời được mở rộng bằng cách bao gồm cả các địa chỉ trong tùy chọn IA_TA gửi trong bản tin Renew hoặc Rebind tới một máy chủ. Ví dụ, một máy khách sẽ yêu cầu mở rộng thời gian tồn tại của một địa chỉ tạm thời để cho phép một ứng dụng được tiếp tục sử dụng một kết nối TCP đã thiết lập. Máy khách có được địa chỉ tạm thời mới bằng cách gửi một tùy chọn IA_TA với một IAID mới đến máy chủ. Yêu cầu địa chỉ tạm thời mới từ máy chủ tương đương với việc tạo địa chỉ tạm thời mới như mô tả trong RFC 3041. Máy chủ sẽ tạo địa chỉ tạm thời mới và trả lại cho máy khách. Máy khách nên yêu cầu địa chỉ tạm thời mới trước khi thời gian tồn tại trên địa chỉ được chỉ định trước đó hết hiệu lực. Máy chủ PHẢI trả lại cùng một tập địa chỉ tạm thời cho cùng một IA _ TA (do IAID xác định) miễn là những địa chỉ này vẫn còn hiệu lực. Sau khi thời gian tồn tại của các địa chỉ trong một IA_TA đã hết hạn, các IAID có thể được sử dụng lại để xác định một IA_TA mới với địa chỉ tạm thời mới. Tùy chọn này CÓ TH Ể xuất hiện trong một bản tin xác nhận nếu thời gian tồn tại tr ê n các địa chỉ tạm thời trong IA liên quan vẫn chưa hết hạn. 22.6. Tùy chọn địa chỉ IA Tùy chọn địa chỉ IA được sử dụng đ ể xác định các địa chỉ IPv6 liên kết với một IA_NA hoặc một IA_TA. Tùy chọn địa chỉ IA PHẢI được đóng gói trong trường tùy ch ọ n của IA_NA hoặc tùy chọn IA_TA. Trường tùy chọn đóng g ó i các tùy chọn cụ thể cho địa chỉ này. Định dạng của tùy chọn đ ố i với địa chỉ IA là: Mã của tùy chọn: là IAADDR-OPTION (5) Option len: là 24 + độ dài của trường tùy chọn I Aaddr IPv6 address: là danh sách các địa chỉ IPv6 Pre f erred li f etime: thời gian tồn tại phù hợp cho các địa chỉ IPv6 trong các tùy chọn, được thể hiện bằng đơn v ị giây. Valid - li f etime: là thời gian tồn tại hợp lệ cho các địa chỉ IPv6 trong các tùy chọn, thể hiện bằng đơn v ị giây. I Aaddr - options: là các tùy chọn liên kết với địa chỉ này. Trong bản tin được gửi từ máy khách đến máy chủ, các giá trị trong trường thời gian tồn tại phù hợp và thời gian tồn tại hợp lệ sẽ chỉ ra các ưu tiên của máy khách đối với những thông số này. Máy khách có thể gửi 0 nếu không có ưu tiên. Trong bản tin gửi từ máy chủ đến máy khách, máy khách PHẢI sử dụng các giá trị có trong trường thời gian tồn tại phù hợp và thời gian tồn tại hợp lệ đ ể đặt cho các tham số này. Các giá trị này là số giây còn lại trong mỗi thời gian tồn tại. Máy khách loại bỏ t ấ t cả các địa chỉ có thời gian tồn tại phù hợp lớn hơn thời gian tồn tại hợp lệ. Máy chủ sẽ bỏ qua các tập hợp thời gian tồn tại do máy khách đặt nếu thời gian tồn tại phù hợp lớn hơn so với thời gian tồn tại hợp lệ và b ỏ qua các giá trị của T1 và T2 được thiết lập bởi các máy khách nếu những giá trị này lớn hơn so với thời gian tồn tại phù hợp. Nên cẩn thận trong việc thiết lập thời gian t ồ n tại hợp lệ của một địa chỉ là 0 xffffffff (không xác định), việc đó dẫn tới việc ch ỉ định vĩnh viễn địa chỉ cho máy khách. Trong một tùy chọn IA_NA hoặc một tùy chọn IA_TA có thể ch ỉ xuất hiện một tùy chọn địa chỉ IA. Nhưng trong một tùy chọn IA_NA hoặc một tùy chọn IA_TA có khả năng xuất hiện nhiều hơn một tùy chọn địa chỉ IA. Trạng thái của bất kỳ hoạt động n à o có liên quan đến địa chỉ IA này đều được chỉ ra trong tùy chọn Status Code chứa trong trường I Aaddr-option. 22.7. Tùy chọn Option Request Tùy chọn Option Request được sử dụng đ ể xác đ ị nh một danh sách các tùy chọn trong một bản tin giữa máy khách và máy chủ. Định dạng của Tùy chọn Option Request là: Mã của tùy chọn: OPTION_ORO (6) Option-len: là 2 * số lượng tùy chọn được yêu cầu Requested-option-code-n: là mã tùy chọn cho một tùy chọn được yêu cầu của máy khách. Máy khách CÓ THỂ gộp một tùy chọn Option Request trong một bản tin Solicit, Request, Renew, Rebind, Confirm hoặc bản tin Information-Request đ ể thông báo cho máy chủ về các tùy chọn mà máy khách muốn máy chủ gửi cho. Một máy chủ CÓ THỂ gộp tùy chọn Option Request trong một tùy chọn Recon f igure để chỉ ra tùy chọn mà máy khách nên yêu cầu từ máy chủ. 22.8. Tùy chọn Pre f erence Tùy chọn Pre f erence được một máy chủ gửi tới máy khách sẽ ảnh hưởng đến việc lựa chọn một máy chủ của máy khách. Định dạng của tùy chọn Pre f erence là: Mã của tùy chọn: l à OPTION-PREFERENCE (7). Option - len: l à 1. Pref-value: là giá trị thích hợp đối với máy chủ trong bản tin đ ó . Một máy chủ CÓ TH Ể gộp tùy chọn Preference trong một bản tin Advertise để kiểm soát việc lựa chọn máy chủ của máy khách. Phần 17.1.3 hướng dẫn sử dụng các tùy chọn Preference cho máy khách và giải thích các giá trị dữ liệu của tùy chọn Pre f erence. 22.9. Tùy chọn Elapsed Time Mã của tùy ch ọ n: OPTION_ELAPSED_TIME (8) Option-len : 2. Elapsed Time: là lượng thời gian k ể từ khi máy khách bắt đầu giao dịch DHCP hiện tại. Thời gian này được thể hiện trong một phần trăm của một giây (1/100 giây). Một máy khách PHẢI gửi kèm tùy chọn Elapsed Time trong bản tin để cho biết máy khách đã cố gắng bao lâu đ ể hoàn thành việc trao đổi một bản tin DHCP. Elapsed Time được tính từ thời gian mà máy khách gửi bản tin đầu tiên trong quá trình trao đổi bản tin và trường thời gian đã sử dụng được đặt là 0 trong bản tin đầu tiên của quá trình trao đổi bản tin. Máy chủ và các nút mạng trung gian sử dụng giá trị dữ liệu trong tùy chọn này như là giá trị đầu vào nhằm kiểm soát xem máy chủ đáp ứng với một bản tin của máy khách như thế nào. Ví dụ, tùy chọn thời gian đã sử dụng cho phép máy chủ DHCP thứ cấp đáp ứng yêu cầu khi máy chủ chính không trả lời sau một khoảng thời gian hợp lý. Giá trị thời gian đã sử dụng l à một số nguyên không dấu, 16 bit. Máy khách sử dụng giá trị 0 xffff để biểu diễn bất kỳ giá tr ị thời gian đã sử dụng nào có giá trị lớn hơn giá trị thời gian lớn nhất có thể được biểu diễn trong các tùy chọn thời gian đã sử dụng. 22.10. T ù y chọn Relay Message Tùy chọn Relay Message mang một bản tin DHCP trong bản tin Relay-forward hoặc bản tin Relay- reply. Định dạng của tùy chọn Relay Message là: Mã của tùy chọn: OPTION_RELAY_MSG (9) Option-len: Độ dài của trường DHCP-relay-message DHCP-relay-message: Trong một bản tin Relay-forward, bản tin nhận được sẽ được chuyển tiếp đúng nguyên vẹn tới nút mạng trung gian tiếp theo hoặc máy chủ; Trong một bản tin Relay-reply, bản tin được sao chép và chuyển tiếp tới nút trung chuyển hoặc máy khách có địa chỉ trong trường địa chỉ ngang hàng (peer - address) của bản tin Relay-reply. 22.11. Tùy chọn Authentication Tùy chọn Authentication mang thông tin xác thực để xác thực danh tính và nội dung của các bản tin DHCP. Việc sử dụng tùy chọn Authentication được mô tả trong phần 21. Định dạng của tùy chọn Authentication là: Mã của tùy chọn: là OPTION_AUTH (11) Option-len: là 11 + Độ dài của trường thông tin xác thực Protocol: là giao thức xác thực được sử dụng trong phương xác xác thực Algorithm: Thuật toán được sử dụng trong giao thức xác thực RDM: là phương pháp phát hiện trung gian được sử dụng trong tùy chọn Authentication này replay detection: l à thông tin phát hiện trung gian cho RDM auth-info: Thông tin xác thực được định nghĩa bởi giao thức và thuật toán sử dụng trong tùy chọn Authentication này. 22.12. Tùy chọn Server Unicast Máy chủ gửi tùy chọn này tới máy khách khác đ ể chỉ báo cho máy khách rằng tùy chọn truyền unicast được phép sử dụng. Định dạng của tùy chọn truyền unicast là: Mã của tùy chọn: là OPTION_UNICAST (12) Option-len: 16 Địa chỉ của máy chủ: Địa chỉ IP mà máy khách cần gửi bản tin sử dụng unicast tới. Máy chủ xác định địa chỉ IPv6 m à máy khách gửi một bản tin unicast trong trường địa chỉ của máy chủ. Khi máy khách nhận được tùy chọn này vào thời điểm thích hợp, máy khách sẽ gửi bản tin trực tiếp đến máy chủ bằng cách sử dụng địa chỉ IPv6 quy định trong trường địa chỉ của máy chủ của tùy chọn truyền này. Khi máy chủ gửi tùy chọn truyền Unicast cho máy khách, một số bản tin từ phía máy khách sẽ không được các nút mạng trung gian chuyển tiếp và tùy chọn unicast này không bao gồm tùy ch ọ n nút mạng trung gian từ các nút mạng trung gian. Vì vậy, một máy chủ chỉ nên gửi một tùy chọn truyền unicast cho máy khách khi các nút mạng trung gian không gửi tùy chọn nút mạng trung gian. Máy chủ DHCP sẽ từ chối gửi bản tin không thích hợp sử dụng tùy chọn truyền unicast đ ể đ ả m bảo rằng bản tin được các nút mạng trung gian chuyển tiếp khi chức năng lựa chọn nút mạng trung gian được sử dụng. Thông tin chi tiết về việc khi nào máy khách có thể gửi bản tin đến máy chủ sử dụng unicast được nêu trong Điều 18. 22.13. T ù y chọn Status Code Tùy chọn này trả về một chỉ báo cho biết tình trạng có liên quan đến bản tin DHCP hoặc chính tùy chọn mà nó xuất hiện trong đó. Định dạng của tùy chọn Status Code là: Mã của tùy chọn: OPTION_STATUS_CODE (13) Option-len (độ dài tùy chọn): 2 + Độ dài của bản tin trạng thái status-code (mã trạng thái): Mã dạng số cho trạng thái được mã hóa trong tùy chọn này. Các mã trạng thái được nêu trong Điều 24.4. Bản tin trạng thái: Văn bản dạng chuỗi mã hóa kiểu UTF-8 phù hợp để hiển thị cho người dùng cuối, KHÔNG ĐƯỢC ở dạng không kết thúc. Tùy chọn Status Code có thể xuất hiện trong các trường tùy chọn của bản tin DHCP và/ hoặc trong các trường tùy chọn của các tùy chọn khác. Nếu Tùy chọn Status Code không xuất hiện trong một bản tin mà trong bản tin đó tùy chọn có thể xuất hiện, tình trạng của bản tin được cho l à thành công. 22.14. Tùy chọn Rapid Commit Tùy chọn Rapid Commit được sử dụng để báo hiệu việc sử dụng hai bản tin trao đổi có mục đích gán địa chỉ. Định dạng của tùy chọn Rapid Commit là: Mã của tùy chọn : OPTION_RAPID_COMMIT (14) Option-len (độ dài tùy chọn): 0 Một máy khách CÓ THỂ gộp tùy chọn này trong một bản tin Request nếu máy khách chuẩn bị để thực hiện việc trao đổi bản tin Solicit-Reply như mô tả trong phần 17.1.1. Máy chủ PHẢI bao gồm các tùy chọn này trong bản tin Reply được gửi trong phản hồi đ ố i với bản tin Solicit khi hoàn thành việc trao đổi bản tin Solicit-Reply. THẢO LUẬN: Mỗi máy chủ sẽ đáp ứng một trả lời cho một yêu cầu trong tùy chọn Rapid Commit sẽ gán các địa chỉ được chỉ định trong bản tin Reply cho máy khách và sẽ không nhận bất kỳ xác nhận là máy khách đã nhận được bản tin Reply. Do đó, nếu nhiều hơn một máy chủ đáp ứng yêu cầu trong tùy chọn Rapid Commit, một số máy chủ sẽ được gán cho các địa chỉ không sử dụng trong thực tế của máy khách. Các vấn đề về địa chỉ không sử dụng có thể được giảm thiểu, ví dụ, bằng cách thiết kế các dịch vụ DHCP sao cho chỉ có một máy chủ đáp ứng với yêu cầu hoặc bằng cách sử dụng thời gian tồn tại tương đối ngắn cho các địa chỉ được chỉ định. 22.15. Tùy chọn User Class Tùy chọn User Class được máy khách sử dụng để xác định các loại và d anh mục người sử dụng hoặc các ứng d ụng mà nó đại diện . Định dạng của tùy chọn User Class như sau: Mã của tùy chọn: là OPTION_USER_CLASS (15) Option-len: là Độ dài của trường dữ liệu phân lớp User-class-data: Lớp người sử dụng được thực hiện bởi máy khách. Các thông tin trong vùng dữ liệu của tùy chọn này được chứa trong một hoặc nhiều trường không rõ ràng đại diện cho lớp người sử dụng hoặc các lớp trong đó máy khách là thành viên. Một máy chủ lựa chọn thông tin cấu hình cho máy khách dựa trên các lớp xác định trong tùy chọn n à y. Ví dụ, bằng tùy chọn User Class có thể sử dụng để cấu hình tất cả các máy khách của nhân viên trong bộ phận k ế toán với một máy in khác so với máy khách của nhân viên trong bộ phận tiếp thị. Thông tin lớp người sử dụng thực hiện trong tùy chọn này PHẢI được cấu hình trên máy khách. Vùng dữ liệu của các tùy chọn User Class PHẢI chứa một hoặc nhiều trường hợp của lớp dữ liệu người dùng. Mỗi trường hợp của các lớp dữ liệu người sử dụng được định dạng như sau: User-class-len có độ dài là hai octec d à i và xác định độ dài của dữ liệu lớp người sử dụng không trong suốt theo thứ tự byte mạng. Một máy chủ diễn tả các lớp được xác định trong tùy chọn này dựa theo cấu hình của nó để chọn ra thông tin cấu hình phù hợp cho máy khách. Một máy chủ có thể chỉ sử dụng những lớp người dùng được cấu hình để diễn tả việc lựa chọn các thông tin cấu hình cho một máy khách và bỏ qua bất kỳ lớp người sử dụng khác. Khi đáp ứng một bản tin có chứa tùy chọn User Class, một máy chủ bao gồm một tùy chọn User Class chứa những lớp được diễn tả thành công b ở i các máy chủ, sao cho máy khách có thể được thông báo về các lớp được máy chủ diễn tả. 22.16. Tùy chọn Vendor Class Tùy chọn này được sử dụng để xác định nhà cung cấp sản xuất ra phần cứng mà máy khách đang sử dụng. Các thông tin trong vùng dữ liệu của tùy chọn này được chứa trong một hoặc nhiều trường mờ để xác định chi tiết về cấu hình phần cứng. Định dạng của tùy chọn Vendor Class là: Mã của tùy chọn: là OPTION_VENDOR_CLASS (16) Option - len: là 4 + Độ dài của trường dữ liệu lớp nhà s ả n xuất enterprise-number: số đăng ký của nhà sản xuất là số đăng ký IA_NA. vendor-class-data: cấu hình phần cứng của host mà trên đó máy khách đang sử dụng. Dữ liệu về các nhà sản xuất bao gồm một loạt các mặt hàng riêng biệt, mỗi mặt hàng mô tả một số đặc điểm của cấu hình phần cứng của máy khách. Ví dụ trường hợp dữ liệu lớp nhà sản xuất có thể bao gồm các phiên bản của hệ điều hành mà máy khách đang s ử dụng hoặc số lượng bộ nhớ được cài đặt trên máy khách. Mỗi trường hợp của dữ liệu lớp nhà s ả n xuất được định dạng như sau: Vendor-class-len dài hai octet và xác định độ dài của các lớp dữ liệu nhà sản xuất mờ trong thứ tự byte mạng. 22.17. Tùy chọn Vendor-speci f ic Information Tùy chọn n à y được sử dụng để máy khách và máy chủ trao đổi thông tin về một nhà s ả n xuất cụ thể. Định dạng của tùy chọn Vendor-speci f ic Information như sau: Mã của tùy chọn: là OPTION_VENDOR_OPTS (17). Option - len: là 4 + Độ dài của trường dữ liệu tùy chọn, enterprise-number: S ố đăng ký của nhà sản xuất là số đăng ký IA_NA. Option - data: là một vật không trong suốt của octet option - len, thể hiện b ằ ng mã nhà sản xuất cụ thể trên máy khách và máy chủ. Việc xác định các thông tin thực hiện trong tùy chọn này l à nhà sản xuất cụ thể. Các nhà cung cấp được chỉ định trong trường số doanh nghiệp. Việc sử dụng thông tin nhà sản xuất cụ thể cho phép tăng cường hoạt động, sử dụng các tính năng bổ sung khi thực hiện DHCP của nhà cung cấp. Một máy khách DHCP mà không nhận được yêu cầu thông tin nhà sản xuất cụ thể vẫn sẽ cấu hình các thiết bị lưu trữ của IPv6 theo chức năng. Trường của tùy chọn vendor-specific được đóng gói PHẢI được mã hóa như l à một chuỗi các mã / Độ dài / giá trị trường của định dạng đồng đẳng đối v ớ i các trường tùy chọn DHCP. Các m ã tùy chọn được xác định bởi các nhà sản xuất được xác định trong trường số doanh nghiệp và không được IA_NA quản lý. Mỗi tùy chọn đã đóng gói được định dạng như sau: Opt - code: l à mã đối với tùy chọn đóng gói Option - len: Một số nguyên không dấu biểu thị Độ dài của trường tùy chọn dữ liệu trong tùy chọn đóng gói này và có đơn v ị tính là octet. Option - data: Vùng dữ liệu đối với tùy chọn đóng gói Nhiều trường hợp của tùy chọn thông tin về nhà sản xuất cụ thể có thể xuất hiện trong một thông điệp DHCP. Mỗi trường hợp tùy chọn được giải thích theo mã tùy chọn đo các nhà sản xuất đã xác định bởi số doanh nghiệp có trong tùy chọn đ ó xác định. 22.18. Tùy chọn lnterface-id Các nút mạng trung gian CÓ THỂ gửi tùy chọn lnterface-id để xác định các giao diện nhận bản tin của máy khách. Nếu một nút mạng trung gian nhận được một bản tin Reply chuyển tiếp với một tùy chọn Inter f ace-i d , nút mạng trung gian sẽ chuyển tiếp các bản tin tới máy khách thông qua giao diện xác định bởi tùy chọn. Định dạng của tùy chọn lnterface-id là: Mã của tùy chọn OPTION _I NTERFACE _I D (18) Option - len: Độ dài của trường định danh giao diện lnterface-id: Một giá trị không rõ độ dài tùy ý được tạo ra bởi các nút mạng trung gian nhằm xác định một trong những giao diện của nút mạng trung gian. Các máy chủ PHẢI sao chép tùy chọn lnterface-id từ bản tin ReIay-Forward vào bản tin Relay-Reply của máy chủ gửi đến các nút mạng trung gian nhằm đáp ứng bản tin Relay-Forward. Tùy chọn này KHÔNG ĐƯỢC xuất hiện trong bất kỳ bản tin nào trừ bản tin Relay-Forward hoặc bản tin Relay-Reply. Máy chủ CÓ THỂ sử dụng định danh của giao diện cho nguyên tắc ch ỉ định các tham số. Định danh của giao diện NÊN coi như một giá trị không rõ ràng có nguyên tắc chỉ dựa trên việc phù hợp, có nghĩa là, máy chủ KHÔNG NÊN phân tích cú pháp nội bộ các định danh giao diện. Giá trị định danh giao diện của một giao diện NÊN ổ n định và không đổi, ví dụ, sau khi các nút mạng trung gian khởi động lại, nếu định danh giao diện thay đổi, máy chủ sẽ không thể sử dụng một cách tin cậy các định danh này trong nguyên tắc chỉ định tham số. 22.19. Tùy chọn Reconfigure Message Một máy chủ gộp tùy chọn Reconfigure Message trong bản tin Reconfigure nhằm chỉ ra cho máy khách là máy khách đã đáp ứng bản tin Renew hoặc bản tin Information-request hay chưa. Định dạng của lựa chọn này là: Mã của tùy chọn: OPTION_RECONF_MSG (19) Option - len: là 1. Kiểu msg: là 5 cho các bản tin Renew và 11 cho các bản tin Information-request. Lựa chọn bản tin Reconfigure có thể ch ỉ xuất hiện trong bản tin Reconfigure. 22.20. Tùy chọn Reconfigure Accept Một máy khách sử dụng tùy chọn Reconfigure Accept để thông báo cho máy chủ là máy khách muốn nhận bản tin Reconfigure hay không và một máy chủ sử dụng tùy chọn này để trao đổi với máy khách là nó có chấp nhận bản tin Reconfigure hay không. Những đặc tính mặc định khi không có tùy chọn này có ý nghĩa là không mong muốn nhận các bản tin Recon fi gure, hoặc cấu trúc không chấp nhận bản tin Reconfigure đối với máy khách và bản tin của máy chủ một cách tương ứng. Hình sau đưa ra định dạng của tùy chọn Reconfigure Accept: Mã của tùy chọn: OPTION_RECONF_ACCEPT (20) Option - len: 0. 23. Các vấn đề về an toàn bảo mật Các mối đe dọa đ ố i với DHCP vốn là mối đe dọa nội bộ (giả sử một mạng cấu hình phù hợp có cổng DHCPv6 bị chặn trên các c ổ ng biên (perimeter) của doanh nghiệp). Không phụ thuộc vào cấu hình cổng, tuy nhiên, các cuộc tấn công tiềm ẩn từ bên trong trong và ngoài đều giống nhau. Cấu hình không tự động chia sẻ trước các khóa cho IPsec giữa các nút mạng trung gian và các máy chủ không bảo vệ chống lại việc tái hiện bản tin DHCP. Các bản tin tái hiện lại có thể đại diện cho một cuộc tấn công DOS do cạn kiệt tài nguyên xử lý, nhưng không phải qua việc cấu hình sai hoặc cạn kiệt các tài nguyên khác như địa chỉ được gán. Một cuộc tấn công cụ thể vào một máy khách DHCP là việc tạo một máy chủ độc hại với mục đích cung cấp thông tin cấu hình không chính xác cho máy khách. Mục tiêu để thực hiện việc này có thể là tấn công “man-in-the-middle” làm cho máy khách giao tiếp với một máy chủ độc hại thay v ì một máy chủ đ ú ng khi thực hiện một số dịch vụ như DNS hoặc NTP. Các máy chủ độc hại cũng có thể chèn một thông báo từ chối thực hiện dịch vụ bằng cách cấu hình sai máy khách gây ra tất cả các thông tin liên lạc mạng xuất phát t ừ máy khách này đến máy chủ thất bại. Một kiểu tấn công khác đối với máy khách DHCP từ các máy không đúng hoặc máy chủ cấu hình DHCP ngẫu nhiên là trả lời yêu cầu của máy khách với các tham số cấu hình ngẫu nhiên không đúng. Máy khách DHCP có thể là mục tiêu tấn công bằng cách nhận một bản tin Reconfigure từ máy chủ độc hại làm cho máy khách nhận các thông tin cấu hình không chính xác từ máy chủ này. Chú ý là mặc dù máy khách gửi các đáp ứng của n ó (bản tin Renew hoặc bản tin Information-request) thông qua các nút mạng trung gian và vì thế đáp ứng này chỉ do máy chủ chuyển tiếp bản tin DHCP nhận, một máy chủ độc hại có thể gửi một bản tin Reconfigure tới máy khách, theo sau (sau một khoảng thời gian thích hợp) là các bản tin Reply có thể được máy khách chấp nhận. Chính v ì vậy, một máy chủ độc hại không ở trên đường dẫn mạng giữa máy khách và máy chủ có thể vẫn tạo một cuộc tấn công tái cấu hình trên máy khách. Việc sử dụng định d anh giao dịch đó là mã hóa âm thanh và có thể không dự đoán được dễ dàng cũng sẽ làm giảm xác suất thành công của cuộc tấn công. Các mối đe dọa cụ thể đối với một máy chủ DHCP là một máy khách không hợp lệ giả mạo như là một máy khách hợp lệ. Động lực cho điều này có thể là hành vi trộm cắp dịch vụ, hoặc đ ể phá vỡ kiểm toán cho một số các mục đích bất chính. Các đe dọa chung cho cả máy chủ và máy khách là một nguồn tấn công DoS (tấn công từ chối dịch vụ). Các cuộc tấn công điển hình liên quan đến việc cạn kiệt các địa chỉ có sẵn hoặc sự cạn kiệt của CPU hoặc băng thông mạng và có mặt bất cứ lúc nào có một chia sẻ tài nguyên. Trong trường hợp các nút trung chuyển thêm lựa chọn bổ sung đối với bản tin Relay-forward, các bản tin trao đổi giữa các nút mạng trung gian tiếp và các máy chủ có thể được sử dụng để gắn kết một “ man-in-the-middle” hoặc tấn công t ừ chối dịch vụ. Mô hình m ố i đe dọa này không coi sự riêng tư của các nội dung của bản tin DHCP là quan trọng. DHCP không được sử dụng để trao đổi thông tin xác thực hoặc thông tin cấu hình cần phải được giữ bí mật từ các nút mạng khác. DHCP xác thực cung cấp xác thực danh tính của DHCP và máy chủ và sự toàn vẹn của bản tin giao giữa máy khách và máy chủ DHCP. DHCP xác thực không cung cấp bất kỳ sự riêng tư cho nội dung của bản tin DHCP. Các giao thức xác thực chậm được mô tả trong Điều 21.4 sử dụng một khóa bí mật được dùng chung giữa một máy khách và một máy chủ. Việc sử dụng một “lĩnh vực DHCP “ trong các khóa dùng chung cho phép xác định các lĩnh vực quản trị sao cho máy khách có thể chọn các phím hoặc phím thích hợp khi chuyển vùng giữa các lĩnh vực quản trị. Tuy nhiên,các giao thức xác thực trễ không xác định bất kỳ cơ chế dùng chung của các phím, do đó, một máy khách có thể yêu cầu các khóa riêng biệt cho từng lĩnh vực quản trị của nó. Việc sử dụng các ph í m dùng chung có thể có quy mô không tốt và không cung cấp sự phủ nhận của các phím th ỏ a hiệp. Giao thức này tập trung vào giải quyết các vấn đề nội miền khi trao đổi ngoài băng của một khóa dùng chung là khả thi. Do có nguy cơ bị tấn công thông qua các bản tin Reconfigure, máy khách DHCP PHẢI loại bỏ bất kỳ bản tin Reconfigure không bao gồm xác thực hoặc không vượt qua được quá trình xác nhận cho các giao thức xác thực. Giao thức khóa cấu hình lại được mô tả trong Điều 21.5 cung cấp lựa chọn b ả o vệ chống lại việc máy chủ DHCP độc hại sử dụng bản tin Reconfigure đ ể tấn công máy khách theo kiểu t ừ chối dịch vụ hoặc bằng phương thức man-in-the-middle. Giao thức này có thể b ị Hacker khai thác b ằ ng cách chặn các bản tin ban đầu có chứa thông tin về khóa mà máy chủ DHCP sẽ gửi cho máy khách. Giao tiếp giữa máy chủ với một nút mạng trung gian và giao tiếp giữa các nút mạng trung gian có thể được b ả o đảm thông qua việc sử dụng IPsec, như được mô tả trong Điều 21.1. Việc sử dụng cấu hình thủ công và lắp đặt các phím tĩnh là chấp nhận được trong trường hợp này bởi v ì các nút mạng trung gian và máy chủ sẽ thuộc về cùng một miền quản trị và các nút mạng trung gian sẽ yêu cầu cấu hình cụ thể khác (ví dụ, cấu hình của địa chỉ máy chủ DHCP) cũng như cấu hình IPsec. 24. Các vấn đề về IA_NA Tiêu chuẩn này định nghĩa một vài trường tên (name space) mới liên quan tới DHCPv6 và lựa chọn DHCPv6: - Loại bản tin - Các m ã trạng thái - DUID - Các mã của tùy chọn IA_NA thành lập một s ổ đăng ký cho các giá trị của mỗi trường tên này. S ổ đăng ký này được mô tả trong phần còn lại của Điều này. IA_NA sẽ quản lý các trường tên này và tất cả các trường tên sẽ được quản lý riêng biệt với các trường tên được xác định cho DHCPv4. Các địa chỉ multicast mới, các kiểu bản tin, mã trạng thái và các kiểu DUID được chỉ định thông qua các hoạt động tiêu chuẩn. Các mã của tùy chọn DHCP được dự kiến chỉ định sau khi chỉ rõ lựa chọn liên kết sẽ được công bố như một dự thảo Internet và được chuyên gia đánh giá. Việc ch ỉ định cuối cùng của các mã của tùy chọn DHCP sẽ thông qua hoạt động tiêu chuẩn, như định nghĩa trong RFC 2434. Tài liệu này cũng tham khảo ba name space trong Điều 21 có liên quan với lựa chọn xác thực (Điều 22.11). Các name space được xác định bởi các cơ chế xác thực cho DHCPV4 trong RFC 3118:2001. Việc xác thức các name space đan g đăng ký tại IA_NA sẽ áp dụng cho cả DHCPv6 và DHCPv4. Trong tương lai, các thông số kỹ thuật đ ể xác định giao thức, thuật toán và cơ chế RDM mới sẽ được xác định rõ ràng xem các cơ chế mới được sử dụng riêng với DHCPv4, DHCPv 6 hoặc cả hai. 24.1. Các chỉ multicast Điều 5.1 định nghĩa các địa chỉ multicast được IA_NA ch ỉ định sử dụng cho DHCPv6 như sau: Các địa chỉ của máy chủ và tất cả các nút mạng trung gian DHCP: FF02::1:2 Các địa chỉ của tất cả các máy chủ DHCP: FF05::1:3 24.2. Các kiểu bản tin DHCP IA_NA đã ghi lại các loại bản tin sau (định nghĩa trong Điều 5.3). IA_NA sẽ giữ đăng ký loại bản tin DHCP. SOLICIT 1 ADVERTISE 2 REQUEST 3 CONFIRM 4 RENEW 5 REBIND 6 REPLY 7 RELEASE 8 DECLINE 9 RECONFIGURE 10 INFORMATION-REQUEST 11 RELAY-FORW 12 RELAY-REPL 13 24.3. Các tùy chọn DHCP IA_NA đã ghi nhận các m ã tùy chọn sau đây (như quy định tại Điều 22). IA_NA sẽ duy tr ì đăng ký của các mã tùy chọn DHCP. OPTION_CLIENTID 1 OPT I ON_SERVERID 2 OPTION _I A_NA 3 OPTION_IA_TA 4 OPTION_IAADDR 5 OPTION_ORO 6 OPTION_PREFERENCE 7 OPTION_ELAPSED_TIME 8 OPTION_RELAY_MSG 9 OPTION_AUTH 11 OPTION_UNICAST 12 OPTION_STATUS_CODE 13 OPTION_RAPID_COMMIT 14 OPTION_USER_CLASS 15 OPTION_VENDOR_CLASS 16 OPTION_VENDOR_OPTS 17 OPTION_INTERFACE_ID 18 OPTION_RECONF_MSG 19 OPTION_RECONF_ACCEPT 20 24.4. Các mã trạng thái IA_NA đã ghi nhận các mã trạng thái trong b ả ng sau. IA_NA sẽ quản lý định nghĩa của các mã trạng thái bổ sung trong tương lai. Tên Mã Mô tả Success 0 Thành công UnspecFail 1 Không thành công, lý do không xác định. Mã trạng thái n à y được c ả máy khách và máy chủ gửi nh ằ m thông báo việc thực hiện không thành công mà lý do không ch ỉ rõ trong tài liệu này. NoAddrsAvail 2 Máy chủ không còn địa chỉ để chỉ định cho IA(s). NoBinding 3 Bản ghi của máy khách (gắn kết) không có. NotOnLink 4 Tiền tố không phù hợp với kết nối của máy khách. UseMulticast 5 Gửi từ máy chủ tới máy khách để bắt máy khách gửi tới máy chủ các bản tin sử dụng tất cả các nút mạng trung gian DHCP và các địa chỉ của máy ch ủ . 24.5. Định danh đơn DHCP IA_NA đã ghi nhận các loại DUID sau (như định nghĩa trong Điều 9.1). IA_NA sẽ quản lý các định nghĩa của loại DUID bổ sung trong tương lai. DU I D-LLT 1 DUID-EN 2 DUID-LL 3 PHỤ LỤC A (Tham khảo) Biểu diễn của các tùy chọn trong các kiều bản tin Các “*” được tr ì nh bày tương ứng với tùy chọn cho phép trong mỗi loại bản tin DHCP: Client ID Server ID IA_NA IA_TA Opsion Request Pref Time Relay Msg. Auth. Server Unica. Solicit * * * * * Advert. * * * * * Request * * * * * * Confirm * * * * * Renew * * * * * * Rebind * * * * * Decline * * * * * * Release * * * * * * Reply * * * * * * Recon f . * * * * I nform. * (xem ghi chú) * * * R-forw. * * R-repl. * * Ghi chú: Ch ỉ bản tin Information-request được gửi để đáp ứng việc tái cấu trúc (xem Điều 19.4.3). Status Rap. User Vendor Vendor Inter. Recon. Recon. Solicit * * * * * Advert. * * * * * Request * * * * Confirm * * * Renew * * * * Rebind * * * * Decline * * * Release * * * Reply * * * * * * Recon f . * I nform. * * * * R-forw. * * * * R-repl. * * * * PHỤ LỤC B (Tham kh ả o) Biểu diễn của các tùy chọn trong trường Tùy chọn của Tùy chọn DHCP Dấu “*” ch ỉ báo rằng khi tùy chọn có thể xuất hiện trong trường tùy chọn của các tùy chọn khác. Opsion Field IA_NA/ IA_TA IAADDR Relay Forw. Relay Reply Client ID * Server ID * IA_NA/IA_TA * IAADDR * ORO * Preference * Elapsed Time * Relay Message * * Authentic. * Server Uni * Status Code * * * Rapid Comm. * User Class * Vendor Class * Vendor I nfo. * Interf. ID * * Reconf. MSG. * Reconf. Accept * Ghi chú: Tùy chọn Relay Forw” hay “Relay Reply” xuất hiện trong trường tùy chọn của bản tin nhưng ch ỉ có thể xuất hiện trong những bản tin này. THƯ MỤC TÀI LIỆU THAM KHẢO - RFC 3315, Dynamic Host Configuration Protocol for IPv6, 2003 (Giao thức cấu hình động cho Internet phiên bản 6); - TCVN 9802-1:2013, Giao thức internet phiên bản 6 (IPv6) - Phần 1: Quy định kỹ thuật; - RFC 3118, Authentication for DHCP Messages, 2001 (Xác thực các bản tin DHCP); - RFC 2373, IP Version 6 Addressing Architecture, 1998 (Kiến trúc địa chỉ IPv6); - RFC 2136, Dynamic Updates in the Domain Name System, 1997 (Cập nhật động trong DNS). MỤC LỤC 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. Tổng quan 4.1. Các giao thức và định địa chỉ 4.2. Trao đổi máy chủ - khách liên quan tới hai bản tin 4.3. Trao đổi chủ - khách liên quan đến bốn bản tin 5. Các hằng số DHCP 5.1. Các địa chỉ Multicast 5.2. Các cổng UDP 5.3. Các kiểu bản tin DHCP 5.4. Các mã trạng thái 5.5. Các thông số truyền và truyền lại 5.6. Biểu diễn giá trị thời gian và giá trị “vô hạn” của thời gian 6. Các định dạng bản tin ch ủ /khách 7. Định dạng bản tin Nút mạng trung gian/máy chủ 7.1. Bản tin Relay-forward 7.2. Bản tin Relay-reply 8. Biểu diễn và sử dụng các tên miền 9. Định danh đơn DHCP 9.1. Nội dung DUID 9.2. DUID dựa trên địa chỉ tầng liên kết cộng thời gian 9.3. DUID được ấn định bởi nhà cung cấp (thiết bị) dựa trên mã số nhà sản xuất 9.4. DUID dựa trên địa chỉ tầng liên kết 10. Tập định danh 11. Lựa chọn địa chỉ để ấn định cho một IA 12. Qu ả n lý các địa chỉ tạm thời 13. Việc truyền các b ả n tin của một máy khách 14. Độ tin cậy của việc trao đổi bản tin do máy khách khởi tạo 15. Hiệu lực của bản tin 15.1. Sử dụng các Transaction ID 15.2. Bản tin Solicit 15.3. Bản tin Advertise 15.4. Bản tin Request 15.5. Bản tin Confirm 15.6. Bản tin Renew 16. Địa ch ỉ nguồn máy khách và việc lựa chọn giao diện 17. Khởi tạo thăm dò của máy chủ DHCP 18. Trao đổi cấu hình khởi tạo từ máy khách 19. Trao đ ổ i cấu hình khởi tạo từ máy chủ DHCP 20. Hành vi của nút mạng trung gian 21. Xác thực các bản tin DHCP 22. Các tùy chọn DHCP 23. Các vấn đề về an toàn bảo mật 24. Các vấn đề về IA_NA Phụ lục A ( tham khảo): Bi ể u diễn của các tùy chọn trong các kiểu bản tin Phụ lục B (tham khảo): Biểu diễn của các tùy chọn trong trường Tùy chọn của Tùy chọn DHCP