ICS35.030

CCSL80

中華人民共和國國家標準

GB/TXXXXX.3—XXXX

`

面向單棧IPv6網(wǎng)絡的4over6技術要求

第3部分：基于IPv6網(wǎng)絡的IPv4地址動

態(tài)分配

Technicalrequirementsof4over6technologyinIPv6-onlynetwork

—Part3:IPv4addressdynamicallocationbasedonIPv6-onlynetwork

（征求意見稿）

在提交反饋意見時，請將您知道的相關專利連同支持性文件一并附上。

XXXX-XX-XX發(fā)布XXXX-XX-XX實施

GB/TXXXXX.3—XXXX

前言

本文件按照GB/T1.1—2020《標準化工作導則第1部分：標準化文件的結構和起草規(guī)則》的規(guī)定

起草。

GB/TXXXXX《面向單棧IPv6網(wǎng)絡的4over6技術要求》與GB/TXXXXX《IPv6+技術要求》、GB/TXXXXX

《多域純IPv6網(wǎng)絡總體技術要求》共同構成IPv6+創(chuàng)新技術的國家標準體系。

本文件是GB/TXXXXX《面向單棧IPv6網(wǎng)絡的4over6技術要求》的第3部分。GB/TXXXXX計劃發(fā)布了

以下部分：

——第1部分：基于IPv6骨干網(wǎng)的IPv4網(wǎng)絡互聯(lián)

——第2部分：面向IPv6接入網(wǎng)的IPv4互聯(lián)

——第3部分：基于IPv6網(wǎng)絡的IPv4地址動態(tài)分配

注意本文件的某些內(nèi)容可能涉及專利，本文件的發(fā)布機構不承擔識別這些專利的責任。

本文件由中華人民共和國工業(yè)和信息化部提出。

本文件由全國通信標準化技術委員會（SAC/TC485）歸口。

本文件起草單位：清華大學，中國信息通信研究院，國家計算機網(wǎng)絡應急技術處理協(xié)調(diào)中心，中國

電信集團有限公司，中國移動通信集團有限公司，中國聯(lián)合網(wǎng)絡通信集團有限公司，華為技術有限公司，

新華三技術有限公司，中國信息通信科技集團有限公司，上海諾基亞貝爾股份有限公司。

本文件主要起草人：崔勇、吳建平、董江、張蕾、徐璐、許志勇、趙慧玲、曹薊光、田輝、趙鋒、

解沖鋒、孫瓊、陸璐、劉鵬、段曉東、李振斌、范大衛(wèi)、郭大勇、陳端。

2

GB/TXXXXX.3—XXXX

引言

根據(jù)《關于加快推進互聯(lián)網(wǎng)協(xié)議第六版（IPv6）規(guī)模部署和應用工作的通知》，為推動IPv6技術

融合創(chuàng)新、構建IPv6技術創(chuàng)新體系，推動IPv6規(guī)模部署和應用創(chuàng)新成果標準化，我國制定了一系列IPv6

創(chuàng)新技術標準。其中，GB/TXXXXX《面向單棧IPv6網(wǎng)絡的4over6技術要求》是在我國開展IPv6規(guī)模部署

的關鍵時期，為規(guī)范4over6過渡技術要求而制定的標準，擬由3個部分構成。

——第1部分：基于IPv6骨干網(wǎng)的IPv4網(wǎng)絡互聯(lián)。目的在于規(guī)范IPv6骨干網(wǎng)的IPv4網(wǎng)絡互聯(lián)。

——第2部分：面向IPv6接入網(wǎng)的IPv4互聯(lián)。目的在于規(guī)范IPv6接入網(wǎng)采用IPv4公有地址及地

址復用的方式實現(xiàn)用戶與IPv4網(wǎng)絡的雙向互聯(lián)。

——第3部分：基于IPv6網(wǎng)絡的IPv4地址動態(tài)分配。目的在于規(guī)范IPv6網(wǎng)絡用戶支持IPv4地址

動態(tài)分配的機制。

3

GB/TXXXXX.3—XXXX

面向單棧IPv6網(wǎng)絡的4over6技術要求

第3部分：基于IPv6網(wǎng)絡的IPv4地址動態(tài)分配

1范圍

本文件規(guī)定了一種使用DHCPv6協(xié)議在IPv6網(wǎng)絡上動態(tài)分配IPv4地址和其他DHCPv4特定配置參數(shù)的

方法。本文件適用于在純IPv6網(wǎng)絡上客戶端采用DHCPv6協(xié)議向DHCPv6服務器動態(tài)獲取IPv4地址的場景。

2規(guī)范性引用文件

下列文件中的內(nèi)容通過文中的規(guī)范性引用而構成本文件必不可少的條款。其中，注日期的引用文件，

僅該日期對應的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修改單）適用于本

文件。

IETFRFC2131動態(tài)主機配置協(xié)議（DynamicHostConfigurationProtocol）

IETFRFC3046DHCP中繼代理信息選項（DHCPRelayAgentInformationOption）

IETFRFC3315IPv6動態(tài)主機配置協(xié)議（DynamicHostConfigurationProtocolforIPv6）

IETFRFC7341DHCP4o6傳輸[DHCPv4-over-DHCPv6(DHCP4o6)Transport]

3術語和定義

下列術語和定義適用于本文件。

用戶側前端設備CPECustomerPremisesEquipment

客戶側前端設備（也稱為客戶提供的設備），為連接到局域網(wǎng)（LAN）的設備（通常在客戶的站點

/家中）提供訪問Internet服務提供商（ISP）網(wǎng)絡的權限。

DHCP4o6DHCPv4overDHCPv6

用于在DHCPv6消息的有效負載中承載DHCPv4消息的協(xié)議。

DHCP4o6客戶端DHCP4o6client

支持DHCPv6協(xié)議[RFC3315]以及本文件中描述的DHCPv4overDHCPv6協(xié)議的DHCP客戶端。這樣的客

戶端能夠使用DHCPv6請求IPv6配置，并通過DHCPv6請求使用DHCPv4的IPv4配置。

DHCP4o6服務器DHCP4o6server

能夠處理封裝在DHCPv4消息選項中的DHCPv4數(shù)據(jù)包的DHCP服務器。

DHCPv6中繼代理DHCPv6RelayAgent

對DHCPv6消息不做處理，把DHCPv6消息的轉發(fā)給DHCP服務器。

4縮略語

4

GB/TXXXXX.3—XXXX

下列縮略語適用于本文件。

BOOTP：引導協(xié)議（BootstrapProtocol）

CPE：用戶側前端設備（CustomerPremiseEquipment）

DHCP：動態(tài)主機配置協(xié)議（DynamicHostConfigurationProtocol）

MBZ：必須設置為零（MustBeZero）

ORO：選項請求項（OptionRequestOption）

5概述

在純IPv6網(wǎng)絡中，客戶端采用4over6機制實現(xiàn)對IPv4互聯(lián)網(wǎng)服務的訪問。此時，客戶端需要采用

DHCP協(xié)議動態(tài)申請IPv4地址。作為DHCP客戶端，通過IPv6網(wǎng)絡上行鏈路向DHCPv6服務器申請IPv4地址。

本文件規(guī)定了DHCP4o6機制來實現(xiàn)在IPv6網(wǎng)絡上通過DHCPv6協(xié)議實現(xiàn)IPv4動態(tài)申請的方法，主要參考

標準RFC7341。在IPv6過渡技術4over6機制中，通過本文件中的DHCP4o6機制實現(xiàn)IPv4動態(tài)申請與分配，

可用于4over6公有IPv4地址的分配，也可用于共享IPv4地址的動態(tài)分配。本文件規(guī)定的DHCP4o6的部署

可以為如圖1所示方式。

DHCPv6

中繼代理

IPv6網(wǎng)絡IPv6網(wǎng)絡IPv6網(wǎng)絡

DHCP4o6DHCP4o6

客戶端服務器DHCP4o6DHCP4o6

（CPE）客戶端服務器

（CPE）

圖1DHCP4o6協(xié)議服務部署方式

其中，DHCP4o6客戶端可以運行在CPE設備、終端主機或任何支持DHCP客戶端功能的設備上。本文

件以CPE作為示例來描述該機制。這并不排除未來任何需要IPv4配置的終端主機或其他設備實現(xiàn)在

DHCPv6上運行DHCPv4。

6DHCPv6選項消息處理要求

消息類型

在DHCP4o6機制中，主要采用兩個DHCPv6消息來實現(xiàn)在客戶端和服務器之間傳遞DHCPv4over

DHCPv6消息：DHCPv4-QUERY和DHCPv4-RESPONSE。這兩個消息如下。

DHCPv4-QUERY(20)：DHCP4o6客戶端會向DHCP4o6服務器發(fā)送DHCPv4-QUERY消息。這個消息中包

含了一個DHCPv4消息選項，DHCP4o6客戶端使用這個選項向服務器請求IPv4配置參數(shù)。

DHCPv4-RESPONSE(21)：DHCP4o6服務器向DHCP4o6客戶端發(fā)送DHCPv4-RESPONSE消息。它包含一

個DHCPv4消息選項，其中攜帶一個DHCPv4消息，作為對DHCPv4-QUERY消息中DHCPv4消息選項接收到的

DHCPv4消息的響應。

消息格式

本文件規(guī)定的兩條DHCPv6消息格式如圖2所示：

5

GB/TXXXXX.3—XXXX

圖2DHCPv4查詢和DHCPv4響應消息的格式

msg-type：標識消息類型。它可以是DHCPv4-QUERY(20)或DHCPv4-RESPONSE(21)。

flags：指定標志位，提供服務器處理DHCPv4-QUERY消息中封裝的DHCPv4消息所需的附加信息，或

者提供客戶端處理DHCPv4-RESPONSE消息中封裝的DHCPv4消息所需的附加信息。

options：消息攜帶的選項。必須攜帶DHCPv4消息選項。此字段只能包含用于IPv4配置的DHCPv6選

項。它不能包含僅與IPv6或僅與IPv6服務配置相關的DHCPv6選項。

DHCPv4查詢消息標志

DHCPv4-QUERY的“標志（flags）”字段用于攜帶額外信息，這些信息可能被服務器用于處理封裝

的DHCPv4消息。目前，該字段僅使用一個比特位。其余比特位保留用于未來使用。“標志”字段的格式

如圖3所示：

圖3DHCPv4查詢標志格式

U：單播標志。若設置為1，則表示如果使用IPv4發(fā)送，DHCPv4-QUERY消息內(nèi)封裝的DHCPv4消息將被

發(fā)送到單播地址。若該標志設置為0，則表示如果使用IPv4發(fā)送，DHCPv4消息將被發(fā)送到廣播地址。

MBZ：這些比特位在發(fā)送時必須設置為0，在接收時必須被忽略。

DHCPv4響應消息標志

本文件在DHCPv4-RESPONSE消息的標志位字段中不引入任何標志。它們都保留供將來使用。DHCP4o6

服務器必須將此字段的所有位設置為0，并且DHCP4o6客戶端必須忽略此字段中的內(nèi)容。

DHCPv4消息選項格式

DHCPv4消息選項攜帶由客戶端或服務器發(fā)送的DHCPv4消息。此類消息不包括任何IP或UDP頭。

DHCPv4消息選項的格式如圖4所示：

6

GB/TXXXXX.3—XXXX

圖4DHCPv4消息選項格式

選項碼（option-code）：取值為OPTION_DHCPv4_MSG（87）。

選項長度（option-len）：即DHCPv4消息的長度。

IPv6地址（DHCPv4-message）：客戶端或服務器發(fā)送的DHCPv4消息。在DHCPv4-QUERY消息中，它包

含客戶端發(fā)送的DHCPv4消息。在DHCPv4-RESPONSE消息中，它包含服務器發(fā)送的DHCPv4消息，作為對客

戶端的響應。

DHCP4o6服務器地址選項格式

DHCP4o6服務器地址選項是由服務器發(fā)送給使用DHCPv6[RFC3315]請求IPv6配置的客戶端的。它攜

帶了一個包含客戶端應聯(lián)系以獲取IPv4配置的DHCP4o6服務器的IPv6地址列表。此列表可能包括多播

和單播地址。客戶端將其請求發(fā)送到此選項中攜帶的所有唯一地址。

此選項也可以不攜帶任何IPv6地址，這會指示客戶端將所有的DHCPRelay代理和服務器多播地址

用作目標地址。

該選項在服務器的響應中的存在指示客戶端應使用DHCPv4-over-DHCPv6來獲取IPv4配置。如果該選

項不存在，則客戶端不得啟用DHCPv4-over-DHCPv6功能。

DHCP4o6服務器地址選項的格式如圖5所示：

圖5DHCP4o6服務器地址選項格式

選項碼（option-code）：OPTION_DHCP4_O_DHCP6_SERVER（88）。

選項長度（option-len）：此選項攜帶的IPv6地址長度，即16個八位組的倍數(shù)。此選項的最小長度

為0。

IPv6地址（DHCPv4-message）：DHCP4o6服務器的一個或多個IPv6地址。

DHCPv4查詢單播標志的使用要求

7

GB/TXXXXX.3—XXXX

DHCPv4客戶端可以根據(jù)其狀態(tài)將其DHCP-REQUEST消息發(fā)送到廣播或單播地址。例如，在續(xù)訂狀態(tài)下

的客戶端使用單播地址與DHCPv4服務器聯(lián)系以續(xù)訂其租約。處于REBINDING狀態(tài)的客戶端使用廣播地址。

在DHCPv4overDHCPv6中，IPv6用于將DHCPv4消息傳遞到DHCP4o6服務器。外部IPv6地址與內(nèi)部

DHCPv4消息之間沒有關系。因此，服務器無法通過檢查IPv6地址確定接收到的DHCPv4消息是否使用IPv4

的廣播還是單播發(fā)送。

為了允許服務器確定客戶端的狀態(tài)，DHCPv4查詢消息中帶有單播標志。如果使用DHCPv4overIPv4，

客戶端必須在DHCPv4消息將要發(fā)送到單播地址時將此標志設置為1。如果DHCPv4客戶端將消息發(fā)送到

IPv4的廣播地址，則必須將此標志設置為0。是否將給定的消息發(fā)送到廣播或單播地址是基于[RFC2131]

及其擴展進行選擇。

7DHCP4o6客戶端行為要求

客戶端在使用DHCPv4overDHCPv6之前必須從DHCPv6服務器獲取必要的IPv6配置。客戶端

在每個Solicit、Request、Renew、Rebind和Information-request消息中使用OptionRequest項

（ORO）請求DHCP4o6服務器地址選項。如果DHCPv6服務器在其響應消息中包括DHCP4o6服務器

地址選項，則表示客戶端可以使用DHCPv4overDHCPv6來獲取IPv4配置。如果DHCPv6服務器沒

有包括DHCP4o6服務器地址選項，則客戶端不得使用DHCPv4overDHCPv6請求IPv4配置。如果

包含DHCP4o6服務器地址選項的IPv6配置隨后過期，或者如果更新后的IPv6配置不包含DHCP

4o6服務器地址選項，則客戶端必須停止使用DHCPv4overDHCPv6請求或更新IPv4配置。客戶端

只要希望使用DHCPv4overDHCPv6，它就會在發(fā)送給DHCPv6服務器的消息中繼續(xù)請求DHCP4o6服

務器地址選項。

在多宿主配置中，可能會有多個DHCPv6配置同時包含一個DHCP4o6服務器地址選項。在這種

情況下，這些配置被視為獨立的，因此當任何這樣的配置處于活動狀態(tài)時，可以為該配置啟用DHCPv4-

over-DHCPv6功能。

客戶端還可以將這些配置視為互斥的，以便每次只保持一個配置處于活動狀態(tài)。在這種情況下，只

要配置有效，客戶端就會持續(xù)保持相同的配置處于活動狀態(tài)。如果該配置變?yōu)闊o效，但仍有一個或多個

其他配置有效，則客戶端會激活一個剩余的有效配置。

客戶端要采用哪種策略取決于實現(xiàn)：在同一時間保持多個配置處于活動狀態(tài)可能在某些應用程序

中提供有用的冗余性。

如果客戶端收到DHCP4o6服務器地址選項，并且在收到DHCPv6選項的接口上使用DHCPv4

[RFC2131]，則客戶端必須停止使用DHCPv4在此接口上接收的IPv4配置。客戶端應遵守[RFC2131]

第4.4.6節(jié)的描述發(fā)送DHCP-RELEASE來放棄現(xiàn)有租約。只要從DHCPv6服務器接收到DHCP4o6服

務器地址選項，客戶端就不得在此接口上使用DHCPv4。

如果客戶端收到一個不含IP地址的DHCPv4o6服務器地址選項，即該選項為空，則客戶端必須將其請

求發(fā)送到所有的DHCPRelay代理和服務器組播地址。如果該選項中有一個IP地址列表，則客戶端應該

向該選項所攜帶的每個唯一地址發(fā)送請求。

如果客戶端通過向服務器發(fā)送Information-request消息來獲取無狀態(tài)IPv6配置，則客戶端應遵守

[RFC4242]中的規(guī)則定期刷新DHCPv4-over-DHCPv6配置（即DHCP4o6服務器列表）以及其他配置數(shù)據(jù)。

獲取有狀態(tài)IPv6配置的客戶端將在擴展已獲取的IPv6地址的生存期（Renew和Rebind消息）時刷新

DHCPv4-over-DHCPv6功能的狀態(tài)。

客戶端必須使用適當范圍的IPv6地址來作為DHCPv4查詢消息的源地址。當客戶端將DHCPv4查詢消息

發(fā)送到組播地址時，它必須使用鏈路本地地址作為源地址，如[RFC3315]中所述。當客戶端使用單播方

式發(fā)送DHCPv4查詢消息時，源地址必須是預先獲取的適當范圍的地址。

8

GB/TXXXXX.3—XXXX

客戶端生成DHCPv4消息，并將其原樣存儲在DHCPv4查詢消息所攜帶的DHCPv4消息選項中。客戶端必

須在單個DHCPv4查詢消息中放置一個DHCPv4消息選項。客戶端不得在DHCPv4查詢消息中請求DHCP4o6

服務器地址選項。

客戶端必須遵循第6節(jié)定義的規(guī)則，在基于DHCPv4目的地設置單播標志時。

客戶端在接收到DHCPv4響應消息時，必須查找該消息中的DHCPv4消息選項。如果未找到此選項，則

將丟棄DHCPv4響應消息。如果存在DHCPv4消息選項，則客戶端提取其所包含的DHCPv4消息，應遵循

[RFC2131]第4.4節(jié)中所述進行處理。

處理IPv4配置時，客戶端應遵循[RFC2131]第4.1節(jié)中指定的正常DHCPv4重傳要求和策略。DHCPv4查

詢消息沒有明確的傳輸參數(shù)，因為這由DHCPv4“狀態(tài)機”[RFC2131]控制。

客戶端必須實現(xiàn)[RFC4361]以確保設備正確地標識自身。當使用DHCPv4overDHCPv6時，它必須發(fā)

送“客戶端標識符”選項。

8DHCP4o6中繼代理行為要求

當DHCPv6中繼代理接收到DHCPv4-QUERY消息時，它可能無法識別此消息。未知消息必須按照

[RFC7283]的描述進行轉發(fā)。

能夠識別DHCP4o6消息的DHCPv6中繼代理可以允許為此類消息配置一個單獨的目的地址集，以補

充用于轉發(fā)其他DHCPv6消息的目的地址集。為實現(xiàn)此功能，中繼代理檢查接收到的DHCPv6消息類型，并

根據(jù)以下邏輯進行轉發(fā)：

如果消息類型為DHCPv4-QUERY，則將數(shù)據(jù)包作為正常的DHCPv6數(shù)據(jù)包（即DHCPv6/UDP/IPv6）

轉發(fā)到配置的DHCP4o6服務器地址。

對于任何其他DHCPv6消息類型，應遵循[RFC3315]第20節(jié)進行轉發(fā)。

以上邏輯僅允許在最接近客戶端的中繼代理（單個中繼跳躍）上配置單獨的中繼目的地。在單獨的

中繼目的地情況下，不考慮多個中繼跳躍。

9DHCP4o6服務器行為要求

當服務器接收到來自客戶端的DHCPv4-QUERY消息時，它會查找DHCPv4消息選項。如果沒有這個選項，

則服務器會丟棄該數(shù)據(jù)包。此外，服務器可能會通知管理員接收到了這個畸形數(shù)據(jù)包，但這種通知機制

不在本文件的討論范圍內(nèi)。

如果服務器找到了一個有效的DHCPv4消息選項，則提取原始的DHCPv4消息。由于DHCPv4消息被封裝

在DHCPv6消息中，因此缺少DHCPv4服務器實現(xiàn)[RFC2131]通常用于進行地址分配決策的信息，例如轉發(fā)

消息的giaddr和服務器用于與直接連接的客戶端通信的IPv4接口地址。因此，DHCP4o6服務器根據(jù)服務

器管理員確定的本地地址分配策略分配地址。例如，如果通過中繼發(fā)送了DHCPv4-QUERY消息，則服務器

可以使用Relay-forward消息的link-address字段作為查找IPv4子網(wǎng)以分配DHCPv4地址的依據(jù)。如果

DHCPv4-QUERY消息是從直接連接的客戶端發(fā)送的，則服務器可以使用消息的IPv6源地址確定用于DHCPv4

地址分配的適當IPv4子網(wǎng)。

另外，服務器也可以充當DHCPv4中繼代理，并將DHCPv4數(shù)據(jù)包轉發(fā)到“普通”DHCPv4服務器。

服務器應該使用DHCPv4-QUERY消息的“標志”字段來創(chuàng)建響應（服務器到客戶端的DHCPv4消息）。

該字段的使用詳見第6節(jié)。當創(chuàng)建適當?shù)腄HCPv4響應時，服務器將其放入DHCPv4消息選項的有效載荷中，

然后將其放入DHCPv4響應消息中。

如果DHCPv4-QUERY消息直接由服務器接收，則DHCPv4響應消息必須從接收原始消息的接口單播出去。

9

GB/TXXXXX.3—XXXX

如果DHCPv4-QUERY消息是在Relay-forward消息中接收的，則服務器創(chuàng)建一個帶有DHCPv4-

RESPONSE消息的Relay-reply消息，并按照[RFC3315]第20.3節(jié)的說明進行響應。

10

GB/TXXXXX.3—XXXX

參考文獻

[1]YD/T4119-2022基于DHCPv4overDHCPv6的租約查詢技術要求

[2]YD/T3232-2017基于IPv6傳輸?shù)腄HCPv4技術要求

[3]IETF.InformationRefreshTimeOptionforDHCPv6[R/OL].RFC4242.2005,Nov.

[4]IETF.Node-specificClientIdentifiersforDHCPv4[R/OL].RFC4361.2006,Feb.

[5]IETF.HandlingUnknownDHCPv6Messages[R/OL].RFC7283.2014,Jul.

11

GB/TXXXXX.3—XXXX

目次

前言............................................................................2

引言............................................................................3

1范圍................................................................................4

2規(guī)范性引用文件......................................................................4

3術語和定義..........................................................................4

4縮略語..............................................................................4

5概述................................................................................5

6DHCPv6選項消息處理要求..............................................................5

7DHCP4o6客戶端行為要求..............................................................8

8DHCP4o6中繼代理行為要求............................................................9

9DHCP4o6服務器行為要求..............................................................9

參考文獻.......................................................................11

I

GB/TXXXXX.3—XXXX

面向單棧IPv6網(wǎng)絡的4over6技術要求

第3部分：基于IPv6網(wǎng)絡的IPv4地址動態(tài)分配

1范圍

本文件規(guī)定了一種使用DHCPv6協(xié)議在IPv6網(wǎng)絡上動態(tài)分配IPv4地址和其他DHCPv4特定配置參數(shù)的

方法。本文件適用于在純IPv6網(wǎng)絡上客戶端采用DHCPv6協(xié)議向DHCPv6服務器動態(tài)獲取IPv4地址的場景。

2規(guī)范性引用文件

下列文件中的內(nèi)容通過文中的規(guī)范性引用而構成本文件必不可少的條款。其中，注日期的引用文件，

僅該日期對應的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修改單）適用于本

文件。

IETFRFC2131動態(tài)主機配置協(xié)議（DynamicHostConfigurationProtocol）

IETFRFC3046DHCP中繼代理信息選項（DHCPRelayAgentInformationOption）

IETFRFC3315IPv6動態(tài)主機配置協(xié)議（DynamicHostConfigurationProtocolforIPv6）

IETFRFC7341DHCP4o6傳輸[DHCPv4-over-DHCPv6(DHCP4o6)Transport]

3術語和定義

下列術語和定義適用于本文件。

用戶側前端設備CPECustomerPremisesEquipment

客戶側前端設備（也稱為客戶提供的設備），為連接到局域網(wǎng)（LAN）的設備（通常在客戶的站點

/家中）提供訪問Internet服務提供商（ISP）網(wǎng)絡的權限。

DHCP4o6DHCPv4overDHCPv6

用于在DHCPv6消息的有效負載中承載DHCPv4消息的協(xié)議。

DHCP4o6客戶端DHCP4o6client

支持DHCPv6協(xié)議[RFC3315]以及本文件中描述的DHCPv4overDHCPv6協(xié)議的DHCP客戶端。這樣的客

戶端能夠使用DHCPv6請求IPv6配置，并通過DHCPv6請求使用DHCPv4的IPv4配置。

DHCP4o6服務器DHCP4o6server

能夠處理封裝在DHCPv4消息選項中的DHCPv4數(shù)據(jù)包的DHCP服務器。

DHCPv6中繼代理DHCPv6RelayAgent

對DHCPv6消息不做處理，把DHCPv6消息的轉發(fā)給DHCP服務器。

4縮略語

4

GB/TXXXXX.3—XXXX

下列縮略語適用于本文件。

BOOTP：引導協(xié)議（BootstrapProtocol）

CPE：用戶側前端設備（CustomerPremiseEquipment）

DHCP：動態(tài)主機配置協(xié)議（DynamicHostConfigurationProtocol）

MBZ：必須設置為零（MustBeZero）

ORO：選項請求項（OptionRequestOption）

5概述

在純IPv6網(wǎng)絡中，客戶端采用4over6機制實現(xiàn)對IPv4互聯(lián)網(wǎng)服務的訪問。此時，客戶端需要采用

DHCP協(xié)議動態(tài)申請IPv4地址。作為DHCP客戶端，通過IPv6網(wǎng)絡上行鏈路向DHCPv6服務器申請IPv4地址。

本文件規(guī)定了DHCP4o6機制來實現(xiàn)在IPv6網(wǎng)絡上通過DHCPv6協(xié)議實現(xiàn)IPv4動態(tài)申請的方法，主要參考

標準RFC7341。在IPv6過渡技術4over6機制中，通過本文件中的DHCP4o6機制實現(xiàn)IPv4動態(tài)申請與分配，

可用于4over6公有IPv4地址的分配，也可用于共享IPv4地址的動態(tài)分配。本文件規(guī)定的DHCP4o6的部署

可以為如圖1所示方式。

DHCPv6

中繼代理

IPv6網(wǎng)絡IPv6網(wǎng)絡IPv6網(wǎng)絡

DHCP4o6DHCP4o6

客戶端服務器DHCP4o6DHCP4o6

（CPE）客戶端服務器

（CPE）

圖1DHCP4o6協(xié)議服務部署方式

其中，DHCP4o6客戶端可以運行在CPE設備、終端主機或任何支持DHCP客戶端功能的設備上。本文

件以CPE作為示例來描述該機制。這并不排除未來任何需要IPv4配置的終端主機或其他設備實現(xiàn)在

DHCPv6上運行DHCPv4。

6DHCPv6選項消息處理要求

消息類型

在DHCP4o6機制中，主要采用兩個DHCPv6消息來實現(xiàn)在客戶端和服務器之間傳遞DHCPv4over

DHCPv6消息：DHCPv4-QUERY和DHCPv4-RESPONSE。這兩個消息如下。

DHCPv4-QUERY(20)：DHCP4o6客戶端會向DHCP4o6服務器發(fā)送DHCPv4-QUERY消息。這個消息中包

含了一個DHCPv4消息選項，DHCP4o6客戶端使用這個選項向服務器請求IPv4配置參數(shù)。

DHCPv4-RESPONSE(21)：DHCP4o6服務器向DHCP4o6客戶端發(fā)送DHCPv4-RESPONSE消息。它包含一

個DHCPv4消息選項，其中攜帶一個DHCPv4消息，作為對DHCPv4-QUERY消息中DHCPv4消息選項接收到的

DHCPv4消息的響應。

消息格式

本文件規(guī)定的兩條DHCPv6消息格式如圖2所示：

5

GB/TXXXXX.3—XXXX

圖2DHCPv4查詢和DHCPv4響應消息的格式

msg-type：標識消息類型。它可以是DHCPv4-QUERY(20)或DHCPv4-RESPONSE(21)。

flags：指定標志位，提供服務器處理DHCPv4-QUERY消息中封裝的DHCPv4消息所需的附加信息，或

者提供客戶端處理DHCPv4-RESPONSE消息中封裝的DHCPv4消息所需的附加信息。

options：消息攜帶的選項。必須攜帶DHCPv4消息選項。此字段只能包含用于IPv4配置的DHCPv6選

項。它不能包含僅與IPv6或僅與IPv6服務配置相關的DHCPv6選項。

DHCPv4查詢消息標志

DHCPv4-QUERY的“標志（flags）”字段用于攜帶額外信息，這些信息可能被服務器用于處理封裝

的DHCPv4消息。目前，該字段僅使用一個比特位。其余比特位保留用于未來使用。“標志”字段的格式

如圖3所示：

圖3DHCPv4查詢標志格式

U：單播標志。若設置為1，則表示如果使用IPv4發(fā)送，DHCPv4-QUERY消息內(nèi)封裝的DHCPv4消息將被

發(fā)送到單播地址。若該標志設置為0，則表示如果使用IPv4發(fā)送，DHCPv4消息將被發(fā)送到廣播地址。

MBZ：這些比特位在發(fā)送時必須設置為0，在接收時必須被忽略。

DHCPv4響應消息標志

本文件在DHCPv4-RESPONSE消息的標志位字段中不引入任何標志。它們都保留供將來使用。DHCP4o6

服務器必須將此字段的所有位設置為0，并且DHCP4o6客戶端必須忽略此字段中的內(nèi)容。

DHCPv4消息選項格式

DHCPv4消息選項攜帶由客戶端或服務器發(fā)送的DHCPv4消息。此類消息不包括任何IP或UDP頭。

DHCPv4消息選項的格式如圖4所示：

6

GB/TXXXXX.3—XXXX

圖4DHCPv4消息選項格式

選項碼（option-code）：取值為OPTION_DHCPv4_MSG（87）。

選項長度（option-len）：即DHCPv4消息的長度。

IPv6地址（DHCPv4-message）：客戶端或服務器發(fā)送的DHCPv4消息。在DHCPv4-QUERY消息中，它包

含客戶端發(fā)送的DHCPv4消息。在DHCPv4-RESPONSE消息中，它包含服務器發(fā)送的DHCPv4消息，作為對客

戶端的響應。

DHCP4o6服務器地址選項格式

DHCP4o6服務器地址選項是由服務器發(fā)送給使用DHCPv6[RFC3315]請求IPv6配置的客戶端的。它攜

帶了一個包含客戶端應聯(lián)系以獲取IPv4配置的DHCP4o6服務器的IPv6地址列表。此列表可能包括多播

和單播地址。客戶端將其請求發(fā)送到此選項中攜帶的所有唯一地址。

此選項也可以不攜帶任何IPv6地址，這會指示客戶端將所有的DHCPRelay代理和服務器多播地址

用作目標地址。

該選項在服務器的響應中的存在指示客戶端應使用DHCPv4-over-DHCPv6來獲取IPv4配置。如果該選

項不存在，則客戶端不得啟用DHCPv4-over-DHCPv6功能。

DHCP4o6服務器地址選項的格式如圖5所示：

圖5DHCP4o6服務器地址選項格式

選項碼（option-code）：OPTION_DHCP4_O_DHCP6_SERVER（88）。

選項長度（option-len）：此選項攜帶的IPv6地址長度，即16個八位組的倍數(shù)。此選項的最小長度

為0。

IPv6地址（DHCPv4-message）：DHCP4o6服務器的一個或多個IPv6地址。

DHCPv4查詢單播標志的使用要求