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 - Đặc tả giao thức

• Số hiệu: TCVN11237-1:2015
• Loại văn bản: Tiêu chuẩn Việt Nam
• Nơi ban hành: ***
• Người ký: ***
• Ngày ban hành: Năm 2015

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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.

...

...

...

Các nút mạng trung gian trao đổi bản tin với máy chủ để chuyển tiếp các bản tin giữa máy khách và máy chủ mà chúng không được kết nối trong cùng một liên kết.

Tất cả các giá trị trong mào đầu bản tin và trong các tùy chọn đều ở dạng thứ tự byte mạng.

Các tùy chọn được lưu trữ tuần tự trong trường Options, không có phần đệm giữa các tùy chọn. Các tùy chọn tính theo byte nhưng không được sắp theo thứ tự như các đường bao 2 hoặc 4 byte.

Có 02 bản tin nút mạng trung gian và có chung định dạng như sau:

Phần tiếp theo mô tả cách sử dụng phần mào đầu của bản tin Nút mạng trung gian.

7.1. Bản tin 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

...

...

...

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

...

...

...

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

...

...

...

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:

...

...

...

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

...

...

...

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:

...

...

...

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.

...

...

...

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.

...

...

...

- 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

...

...

...

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)

...

...

...

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)

...

...

...

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.

...

...

...

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.

...

...

...

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

...

...

...

- 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:

...

...

...

- 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

...

...

...

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

...

...

...

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

...

...

...

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 đó.

...

...

...

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

...

...

...

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

...

...

...

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.

...

...

...

- 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ủ

...

...

...

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

...

...

...

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.

...

...

...

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

...

...

...

- 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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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.

...

...

...

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.

...

...

...

Đị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.

...

...

...

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.

...

...

...

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

...

...

...

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

...

...

...

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.

...

...

...

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à:

...

...

...

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.

...

...

...

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

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

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

...

...

...

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)

...

...

...

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

...

...

...

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

...

...

...

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.

...

...

...

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:

...

...

...

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:

...

...

...

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.

...

...

...

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.

...

...

...

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,

...

...

...

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

...

...

...

Đị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.

...

...

...

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.

...

...

...

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:

...

...

...

- 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

...

...

...

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

...

...

...

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_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_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

...

...

...

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.

...

...

...

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

...

...

...

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)

...

...

...

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

...

...

...

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

...

...

...

User

Vendor

Vendor

Inter.

Recon.

Recon.

Solicit

*

...

...

...

*

*

*

Advert.

*

*

...

...

...

*

*

Request

*

*

...

...

...

*

Confirm

*

*

*

...

...

...

Renew

*

*

*

...

...

...

*

Rebind

*

*

*

...

...

...

Decline

*

*

*

...

...

...

*

*

*

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.

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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