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

Hiệu lực: Còn hiệu lực Ngày có hiệu lực: 31/12/2015

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 configuration 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 IETF RFC 3315:2003 (Dynamic Host Configuration 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 Configuration Protocol for IPv6 (DHCPv6) – Part 1: Protocol specification

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 words 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 Configuration 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, Guidelines for Writing 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 Autoconfiguration, 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 Configuration 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 identifier)

Đị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 <DUID, IA-type, IAID> (trong đó IA-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 <DUID>.

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 IDentifier)

Đị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ố (Prefix 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 (Interface). 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 (Interface)

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 IA 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 identifier)

Đị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 (Reconfigure key)

Khóa được máy chủ cung cấp cho máy khách để bảo mật cho bản tin Reconfigure.

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 (datagram) 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 danh 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 Information-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_Agents_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 Renew 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 sau đó 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 Confirm 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 Confirm để 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 Release 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 Reconfigure 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 Information-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-REPL (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ạng 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 trung 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-reply 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_TIMEOUT	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 gian 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_TIMEOUT	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_TIMEOUT	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ị 0xffffffff đượ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ó 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 Relay-forward

Bảng sau đây quy định việ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.
link-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 việ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à duy 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 duy 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 (0x0CC084D303000912).

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 diệ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 diệ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 nhiề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ố IAID 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 Identifier (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ỉ ra 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 factor)

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 Solicit, 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 Identifier, tùy chọn Client Identifier 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 tin 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 Identifier 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 Advertise 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 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 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 Identifier 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 Identifier.

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 Reconfigure 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 Advertise 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 Preference (Đ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 Preference 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 Reply 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 Identifier 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 Preference để 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 Reply 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à Rebind).

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 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 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 Reconfigure 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_TIMEOUT

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 cho 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 Identifier để 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- lifetime 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/Reply để 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 Duy trì thời gian đế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 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ỉ 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 gian 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 Information-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 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 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 cho 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 Identifier để 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 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 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 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 Reply:

– 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 Address.

– 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 multicast. 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 IA 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 Code 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 Rebind, 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 DUID của máy chủ và lựa chọn Client Identifier 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 tin 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 Request 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.

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 Reconfigure 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 hay 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 Address.

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 Code đượ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 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 REPLY 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 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.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 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 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 Identification 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 Decline 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 Relay-forward bao gồ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ủ 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 Reconfigure

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 Reconfigure 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 Reconfigure đế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 Reconfigure 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 Reconfigure, 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 Infonmation-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 Relay-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: <phản hồi từ máy chủ>

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 Authentication 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 <vùng DHCP, DUID của máy khách, id của khóa>. Mỗi khóa có một thời gian tồn tại. Khóa có thể không được sử dụng sau khi hết thời gian tồn tại. Các khóa của máy khách được phân phối cho máy khách lú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 Advertise 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 Request/Reply, Solicit/Reply hoặc Information-request/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 Reconfigure, 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 Identification đượ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 Identification 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 Identifier đượ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 IA 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 IA_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 IA_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 IA_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 IA_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à 0xffffffff (“infinity” – vô hạn), thì các giá trị T1 và T2 khuyến nghị cũng là 0xffffffff. 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 IA_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 IAaddr

IPv6 address: là danh sách các địa chỉ IPv6

Preferred lifetime: 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 – lifetime: 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.

IAaddr – 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à 0xffffffff (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 IAaddr-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 Reconfigure để 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 Preference

Tùy chọn Preference đượ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 Preference 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 Preference.

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ị 0xffff để 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à danh 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-specific 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-specific 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 Interface-id, 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_INTERFACE_ID (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 Reconfigure, 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 danh 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 đang đă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, DHCPv6 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

OPTION_SERVERID 2

OPTION_IA_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.

DUID-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	*	*	*		*			*	*
Reconf.	*	*		*				*
Inform.	*	(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	*	*	*	*	*			*
Reconf.							*
Inform.			*	*	*			*
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 Info.	*
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

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
Số, ký hiệu văn bản	TCVN11237-1:2015	Ngày hiệu lực	31/12/2015
Loại văn bản	Tiêu chuẩn Việt Nam	Ngày đăng công báo
Lĩnh vực	Điện lực Giao dịch điện tử	Ngày ban hành	31/12/2015
Cơ quan ban hành	Bộ khoa học và công nghê	Tình trạng	Còn hiệu lực

Các văn bản liên kết

Văn bản được hướng dẫn		Văn bản hướng dẫn
Văn bản được hợp nhất		Văn bản hợp nhất
Văn bản bị sửa đổi, bổ sung		Văn bản sửa đổi, bổ sung
Văn bản bị đính chính		Văn bản đính chính
Văn bản bị thay thế		Văn bản thay thế
Văn bản được dẫn chiếu		Văn bản căn cứ

Tải văn bản

Tải văn bản về Bản PDF/Bản gốc