Network Working Group B. Patel
Request for Comments: 3456 Intel Corp
Category: Standards Track B. Aboba
Microsoft
S. Kelly
Airespace
V. Gupta
Sun Microsystems, Inc.
January 2003
Network Working Group B. Patel
Request for Comments: 3456 Intel Corp
Category: Standards Track B. Aboba
Microsoft
S. Kelly
Airespace
V. Gupta
Sun Microsystems, Inc.
January 2003
Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode
IPsec隧道模式的动态主机配置协议（DHCPv4）配置
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This memo explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host Configuration Protocol (DHCPv4) may be leveraged for configuration. In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a "virtual" address from the corporate network, and then tunneling traffic via IPsec from the host's ISP-assigned address to the corporate security gateway. In IPv4, DHCP provides for such remote host configuration.
本备忘录探讨了IPsec隧道模式下的主机配置要求，并描述了如何利用动态主机配置协议（DHCPv4）进行配置。在许多远程访问场景中，使远程主机出现在本地公司网络上的机制非常有用。这可以通过从公司网络为主机分配一个“虚拟”地址，然后通过IPsec将流量从主机的ISP分配地址隧道传输到公司安全网关来实现。在IPv4中，DHCP提供了这种远程主机配置。
Table of Contents
目录
1. Introduction................................................... 2
1.1 Terminology................................................. 2
1.2 Requirements Language....................................... 3
2. IPsec tunnel mode configuration requirements................... 3
2.1 DHCP configuration evaluation............................... 3
2.2 Summary..................................................... 4
3. Scenario overview.............................................. 4
3.1 Configuration walk-through.................................. 5
4. Detailed description........................................... 6
4.1 DHCPDISCOVER message processing............................. 6
4.2 DHCP Relay behavior......................................... 9
4.3 DHCPREQUEST message processing.............................. 10
4.4 DHCPACK message processing.................................. 10
4.5 Configuration policy........................................ 11
5. Security Considerations........................................ 11
6. IANA Considerations............................................ 12
7. Intellectual Property Statement................................ 12
8. References..................................................... 13
8.1 Normative References........................................ 13
8.2 Informative References...................................... 13
9. Acknowledgments................................................ 14
Appendix - IKECFG evaluation...................................... 15
Authors' Addresses................................................ 17
Full Copyright Statement ......................................... 18
1. Introduction................................................... 2
1.1 Terminology................................................. 2
1.2 Requirements Language....................................... 3
2. IPsec tunnel mode configuration requirements................... 3
2.1 DHCP configuration evaluation............................... 3
2.2 Summary..................................................... 4
3. Scenario overview.............................................. 4
3.1 Configuration walk-through.................................. 5
4. Detailed description........................................... 6
4.1 DHCPDISCOVER message processing............................. 6
4.2 DHCP Relay behavior......................................... 9
4.3 DHCPREQUEST message processing.............................. 10
4.4 DHCPACK message processing.................................. 10
4.5 Configuration policy........................................ 11
5. Security Considerations........................................ 11
6. IANA Considerations............................................ 12
7. Intellectual Property Statement................................ 12
8. References..................................................... 13
8.1 Normative References........................................ 13
8.2 Informative References...................................... 13
9. Acknowledgments................................................ 14
Appendix - IKECFG evaluation...................................... 15
Authors' Addresses................................................ 17
Full Copyright Statement ......................................... 18
In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a "virtual" address from the corporate network, and then tunneling traffic via IPsec from the host's ISP-assigned address to the corporate security gateway. In IPv4, Dynamic Host Configuration Protocol (DHCP) [3] provides for such remote host configuration. This document explores the requirements for host configuration in IPsec tunnel mode, and describes how DHCPv4 may be leveraged for configuration.
在许多远程访问场景中，使远程主机出现在本地公司网络上的机制非常有用。这可以通过从公司网络为主机分配一个“虚拟”地址，然后通过IPsec将流量从主机的ISP分配地址隧道传输到公司安全网关来实现。在IPv4中，动态主机配置协议（DHCP）[3]提供了这种远程主机配置。本文档探讨了IPsec隧道模式下主机配置的要求，并描述了如何利用DHCPv4进行配置。
This document uses the following terms:
本文件使用以下术语：
DHCP client A DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address.
DHCP客户端DHCP客户端或“客户端”是使用DHCP获取配置参数（如网络地址）的Internet主机。
DHCP server A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients.
DHCP服务器DHCP服务器或“服务器”是向DHCP客户端返回配置参数的Internet主机。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [1].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”的解释如[1]所述。
As described in [21], the configuration requirements of a host with an IPsec tunnel mode interface include the need to obtain an IPv4 address and other configuration parameters appropriate to the class of host. In addition to meeting the basic requirements [21], the following additional capabilities may be desirable:
如[21]中所述，具有IPsec隧道模式接口的主机的配置要求包括需要获取IPv4地址和其他适用于主机类别的配置参数。除了满足基本要求[21]，还需要以下附加能力：
a. integration with existing IPv4 address management facilities b. support for address pool management c. reconfiguration when required d. support for fail-over e. maintaining security and simplicity in the IKE implementation. f. authentication where required
a. 与现有IPv4地址管理设施b集成。支持地址池管理。需要时重新配置d。支持故障转移e。在IKE实现中维护安全性和简单性。F需要时进行身份验证
Leveraging DHCP for configuration of IPsec tunnel mode meets the basic requirements described in [21]. It also provides the additional capabilities described above.
利用DHCP配置IPsec隧道模式符合[21]中描述的基本要求。它还提供了上述附加功能。
Basic configuration In IPv4, leveraging DHCPv4 [3] for the configuration of IPsec tunnel mode satisfies the basic requirements described in [21]. Since the required configuration parameters described in [21] are a subset of those already supported in DHCPv4 options [4], no new DHCPv4 options are required, and no modifications to DHCPv4 [3] are required.
IPv4中的基本配置，利用DHCPv4[3]配置IPsec隧道模式满足[21]中描述的基本要求。由于[21]中描述的所需配置参数是DHCPv4选项[4]中已经支持的配置参数的子集，因此不需要新的DHCPv4选项，也不需要对DHCPv4[3]进行修改。
Address management integration Since DHCPv4 is widely deployed for address management today, reuse of DHCPv4 for IPsec tunnel mode address management enables compatibility and integration with existing addressing implementations and IPv4 address management software.
地址管理集成由于DHCPv4目前广泛用于地址管理，因此将DHCPv4重新用于IPsec隧道模式地址管理可实现与现有寻址实现和IPv4地址管理软件的兼容性和集成。
Address pool management As described in [18], DHCPv4 implementations support conditional behavior so that the address and configuration parameters assigned can be dependent on parameters included in the DHCPDISCOVER. This makes it possible for the security gateway to ensure that the remote host receives an IP address assignment from the appropriate address pool, such as via the User Class option, described in [16].
地址池管理如[18]所述，DHCPv4实现支持条件行为，因此分配的地址和配置参数可以依赖于DHCPDISCOVER中包含的参数。这使得安全网关能够确保远程主机从适当的地址池接收IP地址分配，例如通过用户类选项，如[16]所述。
Reconfiguration DHCP supports the concept of configuration leases, and there is a proposal for handling forced reconfiguration [14].
重新配置DHCP支持配置租约的概念，并且有一个处理强制重新配置的建议[14]。
Fail-over support When leveraging DHCPv4, configuration and addressing state is kept on the DHCP server, not within the IKE implementation. As a result, the loss of a tunnel server does not result in the loss of configuration and addressing state, thus making it easier to support fail-over [12].
故障转移支持利用DHCPv4时，配置和寻址状态保留在DHCP服务器上，而不是在IKE实现中。因此，隧道服务器的丢失不会导致配置和寻址状态的丢失，因此更容易支持故障转移[12]。
Security and simplicity Leveraging DHCPv4 also makes it easier to maintain security in the IKE implementation since no IKE modifications are required to support configuration.
利用DHCPv4的安全性和简单性还可以更容易地维护IKE实现中的安全性，因为支持配置不需要IKE修改。
Authentication Where DHCPv4 authentication [5] is required, this can be supported on an IPsec tunnel mode interface as it would be on any other interface.
身份验证在需要DHCPv4身份验证[5]的情况下，可以在IPsec隧道模式接口上支持此功能，就像在任何其他接口上一样。
As described, DHCPv4 [3] meets the IPsec tunnel mode configuration requirements [21], as well as providing additional capabilities. As described in the Appendix, IKECFG [13] does not meet the basic requirements, nor does it provide the additional capabilities. As a result, DHCPv4 is the superior alternative for IPsec tunnel mode configuration.
如上所述，DHCPv4[3]满足IPsec隧道模式配置要求[21]，并提供额外的功能。如附录所述，IKECFG[13]既不满足基本要求，也不提供额外的能力。因此，DHCPv4是IPsec隧道模式配置的最佳选择。
IPsec [2], [6]-[9] is a protocol suite defined to secure communication at the network layer between communicating peers. Among many applications enabled by IPsec, a useful application is to connect a remote host to a corporate intranet via a security gateway, using IPsec tunnel mode. This host is then configured in such a manner so as to provide it with a virtual presence on the internal network. This is accomplished in the following manner:
IPsec[2]、[6]-[9]是一个协议套件，用于在网络层保护通信对等方之间的通信。在IPsec支持的许多应用程序中，一个有用的应用程序是使用IPsec隧道模式，通过安全网关将远程主机连接到企业内部网。然后以这样的方式配置该主机，以便在内部网络上为其提供虚拟存在。这是通过以下方式实现的：
A remote host on the Internet will connect to the security gateway and then establish an IPsec tunnel to it. The remote host then interacts via the IPsec tunnel with a DHCPv4 server which provides the remote host with an address from the corporate network address space. The remote host subsequently uses this as the source address for all interactions with corporate resources. Note that this implies that the corporate security gateway continues to recognize the host's original, routable IP address as the tunnel endpoint. The virtual identity assumed by the remote host when using the assigned address appears to the corporate network as though it were situated behind a security gateway bearing the original routable IP address. All the traffic between the remote host and the intranet will be carried over the IPsec tunnel via the security gateway as shown below:
Internet上的远程主机将连接到安全网关，然后建立到该网关的IPsec隧道。然后，远程主机通过IPsec隧道与DHCPv4服务器交互，DHCPv4服务器向远程主机提供公司网络地址空间中的地址。远程主机随后将其用作与公司资源进行所有交互的源地址。请注意，这意味着公司安全网关将继续将主机的原始可路由IP地址识别为隧道端点。远程主机在使用分配的地址时假定的虚拟身份在公司网络中显示为，好像它位于具有原始可路由IP地址的安全网关后面。远程主机和intranet之间的所有通信将通过安全网关通过IPsec隧道传输，如下所示：
corporate net
+------------------+ |
| externally | +--------+ | !~~~~~~~~~~!
|+-------+ visible | | | | ! rmt host !
||virtual| host | |security| |---! virtual !
|| host | |--------|gateway/| | ! presence !
|| |<================>| DHCP |----| !~~~~~~~~~~!
|+-------+ |--------| Relay | |
+------------------+ ^ +--------+ | +--------+
| |---| DHCPv4 |
IPsec tunnel | | server |
with encapsulated | +--------+
traffic inside
corporate net
+------------------+ |
| externally | +--------+ | !~~~~~~~~~~!
|+-------+ visible | | | | ! rmt host !
||virtual| host | |security| |---! virtual !
|| host | |--------|gateway/| | ! presence !
|| |<================>| DHCP |----| !~~~~~~~~~~!
|+-------+ |--------| Relay | |
+------------------+ ^ +--------+ | +--------+
| |---| DHCPv4 |
IPsec tunnel | | server |
with encapsulated | +--------+
traffic inside
This scenario assumes that the remote host already has Internet connectivity and the host Internet interface is appropriately configured. The mechanisms for configuration of the remote host's address for the Internet interface are well defined; i.e., PPP IP control protocol (IPCP), described in [10], DHCPv4, described in [3], and static addressing. The mechanisms for auto-configuration of the intranet are also standardized. It is also assumed that the remote host has knowledge of the location of the security gateway. This can be accomplished via DNS, using either A, KX [23], or SRV [24] records.
此场景假定远程主机已具有Internet连接，并且主机Internet接口已正确配置。为Internet接口配置远程主机地址的机制定义良好；i、 例如，[10]中描述的PPP IP控制协议（IPCP），[3]中描述的DHCPv4以及静态寻址。内部网的自动配置机制也已标准化。还假定远程主机知道安全网关的位置。这可以通过DNS，使用A、KX[23]或SRV[24]记录来完成。
A typical configuration of the remote host in this application would use two addresses: 1) an interface to connect to the Internet (Internet interface), and 2) a virtual interface to connect to the intranet (intranet interface). The IP address of the Internet and intranet interfaces are used in the outer and inner headers of the IPsec tunnel mode packet, respectively.
此应用程序中远程主机的典型配置将使用两个地址：1）连接到Internet的接口（Internet接口），2）连接到intranet的虚拟接口（intranet接口）。Internet和intranet接口的IP地址分别用于IPsec隧道模式数据包的外部和内部报头。
The configuration of the intranet interface of the IPsec tunnel mode host is accomplished in the following steps:
IPsec隧道模式主机的intranet接口的配置通过以下步骤完成：
a. The remote host establishes an IKE security association with the security gateway in a main mode or aggressive mode exchange. This IKE SA then serves to secure additional quick mode IPsec SAs.
a. 远程主机在主模式或主动模式交换中与安全网关建立IKE安全关联。然后，此IKE SA用于保护其他快速模式IPsec SA。
b. The remote host establishes a DHCP SA with the IPsec tunnel mode server in a quick mode exchange. The DHCP SA is an IPsec tunnel mode SA established to protect initial DHCPv4 traffic between the security gateway and the remote host. The DHCP SA MUST only be used for DHCP traffic. The details of how this SA is set up are described in Section 4.1.
b. 远程主机在快速模式交换中与IPsec隧道模式服务器建立DHCP SA。DHCP SA是一种IPsec隧道模式SA，用于保护安全网关和远程主机之间的初始DHCPv4流量。DHCP SA只能用于DHCP通信。第4.1节描述了如何设置该SA的详细信息。
c. DHCP messages are sent back and forth between the remote host and the DHCPv4 server. The traffic is protected between the remote host and the security gateway using the DHCP SA established in step b. After the DHCP conversation completes, the remote host's intranet interface obtains an IP address as well as other configuration parameters.
c. DHCP消息在远程主机和DHCPv4服务器之间来回发送。使用在步骤b中建立的DHCP SA在远程主机和安全网关之间保护通信量。DHCP对话完成后，远程主机的intranet接口将获得IP地址以及其他配置参数。
d. The remote host MAY request deletion of the DHCP SA since future DHCP messages will be carried over a new IPsec tunnel. Alternatively, the remote host and the security gateway MAY continue to use the same SA for all subsequent traffic by adding temporary SPD selectors in the same manner as is provided for name ID types in [2].
d. 远程主机可能会请求删除DHCP SA，因为将来的DHCP消息将通过新的IPsec隧道传输。或者，远程主机和安全网关可以通过以与[2]中为名称ID类型提供的相同方式添加临时SPD选择器，继续为所有后续通信使用相同的SA。
e. If a new IPsec tunnel is required, the remote host establishes a tunnel mode SA to the security gateway in a quick mode exchange. In this case, the new address assigned via DHCPv4 SHOULD be used in the quick mode ID.
e. 如果需要新的IPsec隧道，远程主机将在快速模式交换中建立到安全网关的隧道模式SA。在这种情况下，应在快速模式ID中使用通过DHCPv4分配的新地址。
At the end of the last step, the remote host is ready to communicate with the intranet using an IPsec tunnel. All the IP traffic (including future DHCPv4 messages) between the remote host and the intranet are now tunneled over this IPsec tunnel mode SA.
在最后一步结束时，远程主机准备好使用IPsec隧道与intranet通信。远程主机和intranet之间的所有IP通信（包括将来的DHCPv4消息）现在都通过此IPsec隧道模式SA进行隧道传输。
Since the security parameters used for different SAs are based on the unique requirements of the remote host and the security gateway, they are not described in this document. The mechanisms described here work best when the VPN is implemented using a virtual interface.
由于用于不同SA的安全参数基于远程主机和安全网关的独特要求，因此本文档中不进行描述。这里描述的机制在使用虚拟接口实现VPN时效果最佳。
This section provides details relating to the messages exchanged during the setup and teardown of the DHCP SAs.
本节提供有关DHCP SAs设置和拆卸期间交换的消息的详细信息。
The events begin with the remote host intranet interface generating a DHCPDISCOVER message. Details are described below:
事件从远程主机intranet接口开始，该接口生成DHCPDISCOVER消息。详情如下：
FIELD OCTETS DESCRIPTION
字段八位字节描述
op 1 Message op code / message type. 1 = BOOTREQUEST, 2 = BOOTREPLY htype 1 Hardware address type. Set to value 31. signifying an IPsec tunnel mode virtual interface. hlen 1 Hardware address length hops 1 Client sets to zero, optionally used by relay agents when booting via a relay agent. xid 4 Transaction ID, a random number chosen by the client, used by the client and server to associate messages and responses between a client and a server. secs 2 Filled in by client, seconds elapsed since client began address acquisition or renewal process. flags 2 Flags. Broadcast bit MUST be set to zero. ciaddr 4 Client IP address; only filled in if client is in BOUND, RENEW or REBINDING state. yiaddr 4 'your' (client) IP address. siaddr 4 IP address of next server to use in bootstrap; returned in DHCPOFFER, DHCPACK by server. giaddr 4 Security gateway interface IPv4 address, used in booting via a relay agent. chaddr 16 Client hardware address. Should be unique. sname 64 Optional server host name, null terminated string. file 128 Boot file name, null terminated string; "generic" name or null in DHCPDISCOVER, fully qualified directory-path name in DHCPOFFER. options var Optional parameters field.
op 1消息op代码/消息类型。1=BOOTREQUEST，2=BOOTREPLY htype 1硬件地址类型。设置为值31。表示IPsec隧道模式虚拟接口。hlen 1硬件地址长度跃变1客户端设置为零，中继代理在通过中继代理引导时可以选择使用。xid 4事务ID，客户端选择的一个随机数，客户端和服务器使用它来关联客户端和服务器之间的消息和响应。客户机填写的秒数2，自客户机开始地址获取或更新过程起已过秒数。旗2旗。广播位必须设置为零。ciaddr 4客户端IP地址；仅当客户端处于绑定、续订或重新绑定状态时填写。yiaddr 4“您的”（客户端）IP地址。要在引导中使用的下一个服务器的siaddr 4 IP地址；在DHCPOFFER中返回，DHCPACK由服务器返回。giaddr 4安全网关接口IPv4地址，用于通过中继代理引导。chaddr 16客户端硬件地址。应该是独一无二的。sname 64可选服务器主机名，以null结尾的字符串。文件128引导文件名，以null结尾的字符串；DHCPDISCOVER中的“通用”名称或null，DHCPOFFER中的完全限定目录路径名。选项变量可选参数字段。
Table 1: Description of fields in the DHCP message
表1:DHCP消息中字段的说明
The htype value is set to the value 31, signifying a virtual IPsec tunnel mode interface, in order to enable the DHCP server to differentiate VPN from non-VPN requests. The chaddr field of the DHCPDISCOVER MUST include an identifier unique to the virtual subnet. The client MUST use the same chaddr field in all subsequent messages within the same DHCPv4 exchange. In addition, the chaddr SHOULD be
htype值设置为值31，表示虚拟IPsec隧道模式接口，以便使DHCP服务器能够区分VPN和非VPN请求。DHCPDISCOVER的chaddr字段必须包含虚拟子网唯一的标识符。客户端必须在同一DHCPv4交换中的所有后续消息中使用相同的chaddr字段。此外，chaddr应该是
persistent between reboots so that the DHCP server will be able to re-assign the same address if desired.
重新启动之间的持久性，以便DHCP服务器能够根据需要重新分配相同的地址。
The hlen and chaddr fields SHOULD be determined as follows:
hlen和chaddr字段应按如下方式确定：
a. If one or more LAN interfaces are available, the hlen and chaddr fields SHOULD be determined from the active LAN interface with the lowest interface number. If no active LAN interface is available, then the parameters SHOULD be determined from the LAN interface with the lowest interface number. This enables the chaddr to be persistent between reboots, as long as the LAN interface hardware is not removed.
a. 如果有一个或多个LAN接口可用，则应根据具有最低接口号的活动LAN接口确定hlen和chaddr字段。如果没有可用的活动LAN接口，则应根据接口号最低的LAN接口确定参数。这使得chaddr在重新启动之间保持不变，只要不移除LAN接口硬件。
b. If there is no LAN interface, the chaddr field SHOULD be determined by concatenating x'4000', the IPv4 address of the interface supplying network connectivity, and an additional octet. The x'4000' value indicates a locally administered unicast MAC address, thus guaranteeing that the constructed chaddr value will not conflict with a globally assigned value.
b. 如果没有LAN接口，则chaddr字段应通过连接提供网络连接的接口的IPv4地址x'4000'和额外的八位字节来确定。x'4000'值表示本地管理的单播MAC地址，从而保证构造的chaddr值不会与全局分配的值冲突。
The additional octet (which MAY represent an interface number) SHOULD be persistent between reboots, so that the chaddr value will be persistent across reboots if the assigned IPv4 address remains consistent.
额外的八位字节（可能表示接口号）应在重新启动之间保持不变，因此，如果分配的IPv4地址保持一致，则chaddr值将在重新启动期间保持不变。
If the above prescription is followed, then the chaddr will always be unique on the virtual subnet provided that the remote host only brings up a single tunnel to the security gateway. Where a LAN interface is available, the chaddr will be globally unique. When a non-LAN interface is available and a unique Internet address is assigned to the remote host, the chaddr will also be globally unique. Where a private IP address [22] is assigned to a non-LAN interface, it will not be globally unique. However, in this case packets will not be routed back and forth between the remote host and the security gateway unless the external network and corporate network have a consistent addressing plan. In this case the private IP address assigned to the remote host will be unique on the virtual subnet.
如果遵循上述规定，则chaddr在虚拟子网上始终是唯一的，前提是远程主机仅向安全网关提供一个隧道。如果有LAN接口，chaddr将是全球唯一的。当非LAN接口可用并且为远程主机分配了唯一的Internet地址时，chaddr也将是全局唯一的。如果将专用IP地址[22]分配给非LAN接口，则该地址不会是全局唯一的。但是，在这种情况下，数据包不会在远程主机和安全网关之间来回路由，除非外部网络和公司网络具有一致的寻址计划。在这种情况下，分配给远程主机的专用IP地址在虚拟子网中是唯一的。
For use in DHCPv4 configuration of IPsec tunnel mode, the client-identifier option MUST be included, MUST be unique within the virtual subnet and SHOULD be persistent across reboots. Possibilities include:
要在IPsec隧道模式的DHCPv4配置中使用，必须包括客户端标识符选项，该选项在虚拟子网中必须是唯一的，并且应在重新启动时保持不变。可能性包括：
a. The htype/chaddr combination. If assigned as described above, this will be unique on the virtual subnet. It will be persistent across reboots for a LAN interface. If a non-LAN interface is used, it may not be persistent across reboots if the assigned IP address changes.
a. htype/chaddr组合。如果如上所述进行分配，则这在虚拟子网中是唯一的。它将在LAN接口的重新启动过程中保持不变。如果使用非LAN接口，如果分配的IP地址发生更改，则该接口可能不会在重新启动期间保持不变。
b. The machine FQDN concatenated with an interface number. Assuming that the machine FQDN does not conflict with that of another machine, this will be unique on the virtual subnet as well as persistent across reboots.
b. 计算机FQDN已与接口号连接。假设机器FQDN与另一台机器的FQDN不冲突，则该FQDN在虚拟子网上是唯一的，并且在重新启动时是持久的。
c. The user NAI concatenated with an interface number. Assuming that the user is only connected to the VPN at one location, this will be unique on the subnet as well as persistent across reboots.
c. 用户NAI与接口号连接。假设用户仅在一个位置连接到VPN，这在子网上是唯一的，并且在重新启动时是持久的。
In order to deliver the DHCPDISCOVER packet from the intranet interface to the security gateway, an IKE Phase 1 SA is established between the Internet interface and the security gateway. A phase 2 (quick mode) DHCP SA tunnel mode SA is then established. The key lifetime for the DHCP SA SHOULD be on the order of minutes since it will only be temporary. The remote host SHOULD use an IDci payload of 0.0.0.0/UDP/port 68 in the quick mode exchange. The security gateway will use an IDcr payload of its own Internet address/UDP/port 67. The DHCP SA is established as a tunnel mode SA with filters set as follows:
为了将DHCPDISCOVER数据包从intranet接口传送到安全网关，在Internet接口和安全网关之间建立IKE阶段1 SA。然后建立第2阶段（快速模式）DHCP SA隧道模式SA。DHCP SA的密钥生存期应为分钟，因为它只是临时的。在快速模式交换中，远程主机应使用IDci有效负载0.0.0.0/UDP/port 68。安全网关将使用其自己的互联网地址/UDP/端口67的IDcr有效负载。DHCP SA建立为隧道模式SA，过滤器设置如下：
From remote host to security gateway: Any to Any, destination: UDP port 67
从远程主机到安全网关：任意到任意，目标：UDP端口67
From security gateway to remote host: Any to Any, destination: UDP port 68
从安全网关到远程主机：任意到任意，目标：UDP端口68
Note that these filters will work not only for a client without configuration, but also with a client that has previously obtained a configuration lease, and is attempting to renew it. In the latter case, the DHCP SA will initially be used to send a DHCPREQUEST rather than a DHCPDISCOVER message. The initial DHCPv4 message (DHCPDISCOVER or DHCPREQUEST) is then tunneled to the security gateway using the tunnel mode SA. Note that since the DHCPDISCOVER packet has a broadcast address destination, the IPsec implementations on both the remote host and the security gateway must be capable of handling this.
请注意，这些过滤器不仅适用于没有配置的客户机，还适用于以前已获得配置租约并正在尝试续订的客户机。在后一种情况下，DHCP SA最初将用于发送DHCPREQUEST而不是DHCPDISCOVER消息。然后，使用隧道模式SA将初始DHCPv4消息（DHCPDISCOVER或DHCPREQUEST）通过隧道传输到安全网关。请注意，由于DHCPDISCOVER数据包具有广播地址目的地，因此远程主机和安全网关上的IPsec实现必须能够处理此问题。
While other configurations are possible, typically the DHCPv4 server will not reside on the same machine as the security gateway, which will act as a DHCPv4 relay, inserting its address in the "giaddr" field. In this case, the security gateway relays packets between the client and the DHCPv4 server, but does not request or renew addresses on the client's behalf. While acting as a DHCP Relay, the security gateway MAY implement DHCP Relay load balancing as described in [19].
虽然可以进行其他配置，但通常DHCPv4服务器不会与安全网关驻留在同一台机器上，安全网关将充当DHCPv4中继，将其地址插入“giaddr”字段。在这种情况下，安全网关在客户端和DHCPv4服务器之间中继数据包，但不代表客户端请求或续订地址。当充当DHCP中继时，安全网关可实现[19]中所述的DHCP中继负载平衡。
Since DHCP Relays are stateless, the security gateway SHOULD insert appropriate information in the DHCP message prior to forwarding to one or more DHCP servers. This enables the security gateway to route the corresponding DHCPOFFER message(s) back to the remote host on the correct IPsec tunnel, without having to keep state gleaned from the DISCOVER, such as a table of the xid, chaddr and tunnel.
由于DHCP中继是无状态的，安全网关应在转发到一个或多个DHCP服务器之前在DHCP消息中插入适当的信息。这使安全网关能够将相应的DHCPOFFER消息路由回正确的IPsec隧道上的远程主机，而无需保留从发现中收集的状态，例如xid、chaddr和隧道的表。
If the security gateway maintains a separate subnet for each IPsec tunnel, then this can be accomplished by inserting the appropriate interface address in the giaddr field. Alternatively, the security gateway can utilize the DHCP Relay Agent Information Option [17]. In this case, the virtual port number of the tunnel is inserted in the Agent Circuit ID Sub-option (sub-option code 1).
如果安全网关为每个IPsec隧道维护一个单独的子网，那么可以通过在giaddr字段中插入适当的接口地址来实现。或者，安全网关可以利用DHCP中继代理信息选项[17]。在这种情况下，隧道的虚拟端口号插入代理电路ID子选项（子选项代码1）。
To learn the internal IP address of the client in order to route packets to it, the security gateway will typically snoop the yiaddr field within the DHCPACK and plumb a corresponding route as part of DHCP Relay processing.
为了了解客户端的内部IP地址，以便将数据包路由到客户端，安全网关通常会在DHCPACK中嗅探yiaddr字段，并作为DHCP中继处理的一部分，探测相应的路由。
Where allocating a separate subnet for each tunnel is not feasible, and the DHCP server does not support the Relay Agent Information Option, stateless Relay Agent behavior will not be possible. In such cases, implementations MAY devise a mapping between the xid, chaddr, and tunnel in order to route the DHCP server response to the appropriate tunnel endpoint. Note that this is particularly undesirable in large VPN servers where the resulting state will be substantial.
如果无法为每个隧道分配单独的子网，并且DHCP服务器不支持中继代理信息选项，则无状态中继代理行为将不可能。在这种情况下，实现可以设计xid、chaddr和隧道之间的映射，以便将DHCP服务器响应路由到适当的隧道端点。请注意，这在产生大量状态的大型VPN服务器中尤其不受欢迎。
After the Internet interface has received the DHCPOFFER message, it forwards this to the intranet interface after IPsec processing. The intranet interface then responds by creating a DHCPREQUEST message, which is tunneled to security gateway using the DHCP SA.
Internet接口收到DHCPOFFER消息后，在IPsec处理后将其转发到intranet接口。然后，内部网接口通过创建DHCPREQUEST消息进行响应，该消息使用DHCP SA通过隧道传输到安全网关。
The DHCPv4 server then replies with a DHCPACK or DHCPNAK message, which is forwarded down the DHCP SA by the security gateway. The remote host Internet interface then forwards the DHCPACK or DHCPNAK message to the intranet interface after IPsec processing.
然后，DHCPv4服务器用DHCPACK或DHCPNAK消息进行回复，该消息由安全网关向下转发到DHCP SA。然后，远程主机Internet接口在IPsec处理后将DHCPACK或DHCPNAK消息转发到intranet接口。
After processing of the DHCPACK, the intranet interface is configured and the Internet interface can establish a new IPsec tunnel mode SA to the security gateway. The remote host may now delete the DHCP tunnel mode SA. All future DHCP messages sent by the client, including DHCPREQUEST, DHCPINFORM, DHCPDECLINE, and DHCPRELEASE messages will use the newly established VPN SA. Similarly, all DHCP
处理DHCPACK后，配置intranet接口，Internet接口可以建立到安全网关的新IPsec隧道模式SA。远程主机现在可以删除DHCP隧道模式SA。客户端将来发送的所有DHCP消息，包括DHCPREQUEST、DHCPInfo、DHCPDecend和DHCPRELEASE消息，都将使用新建立的VPN SA。同样，所有DHCP
messages subsequently sent by the DHCPv4 server will be forwarded by the security gateway (acting as a DHCP Relay) using the IPsec tunnel mode SA, including DHCPOFFER, DHCPACK, and DHCPNAK messages.
随后由DHCPv4服务器发送的消息将由安全网关（充当DHCP中继）使用IPsec隧道模式SA转发，包括DHCPOFFER、DHCPACK和DHCPNAK消息。
It SHOULD be possible to configure the remote host to forward all Internet-bound traffic through the tunnel. While this adds overhead to round-trips between the remote host and the Internet, it provides some added security in return for this, in that the corporate security gateway may now filter traffic as it would if the remote host were physically located on the corporate network.
应该可以将远程主机配置为通过隧道转发所有绑定到Internet的流量。虽然这增加了远程主机和Internet之间往返的开销，但作为回报，它提供了一些额外的安全性，因为企业安全网关现在可以像远程主机实际位于企业网络上一样过滤流量。
Several mechanisms can be used to enable remote hosts to be assigned different configurations. For example, clients may use the User Class Option [16] to request various configuration profiles. The DHCPv4 server may also take a number of other variables into account, including the htype/chaddr; the host name option; the client-identifier option; the DHCP Relay Agent Information option [17]; the vendor-class-identifier option; the vendor-specific information option; or the subnet selection option [15].
可以使用多种机制来为远程主机分配不同的配置。例如，客户端可以使用用户类选项[16]来请求各种配置配置文件。DHCPv4服务器还可以考虑许多其他变量，包括htype/chaddr；主机名选项；客户端标识符选项；DHCP中继代理信息选项[17]；供应商类别标识符选项；供应商特定信息选项；或子网选择选项[15]。
Conditional configuration of clients, described in [18], can be used to solve a number of problems, including assignment of options based on the client operating system; assignment of groups of clients to address ranges subsequently used to determine quality of service; allocation of special address ranges for remote hosts; assignment of static routes to clients [20], etc. As noted in the security considerations, these mechanisms, while useful, do not enhance security since they can be evaded by a remote host choosing its own IP address.
[18]中描述的客户端条件配置可用于解决许多问题，包括基于客户端操作系统的选项分配；分配客户群，以确定随后用于确定服务质量的范围；为远程主机分配特殊地址范围；将静态路由分配给客户端[20]等。如安全注意事项中所述，这些机制虽然有用，但不会增强安全性，因为远程主机可以选择自己的IP地址来规避它们。
This protocol is secured using IPsec, and as a result the DHCP packets flowing between the remote host and the security gateway are authenticated and integrity protected.
该协议使用IPsec进行安全保护，因此，在远程主机和安全网关之间流动的DHCP数据包得到身份验证和完整性保护。
However, since the security gateway acts as a DHCP Relay, no protection is afforded the DHCP packets in the portion of the path between the security gateway and the DHCP server, unless DHCP authentication is used.
然而，由于安全网关充当DHCP中继，除非使用DHCP身份验证，否则在安全网关和DHCP服务器之间的路径部分中不会向DHCP数据包提供保护。
Note that authenticated DHCP cannot be used as an access control mechanism. This is because a remote host can always set its own IP address and thus evade any security measures based on DHCP authentication.
请注意，经过身份验证的DHCP不能用作访问控制机制。这是因为远程主机总是可以设置自己的IP地址，从而规避任何基于DHCP身份验证的安全措施。
As a result, the assigned address MUST NOT be depended upon for security. Instead, the security gateway can use other techniques such as instantiating packet filters or quick mode selectors on a per-tunnel basis.
因此，分配的地址不能依赖于安全性。相反，安全网关可以使用其他技术，例如在每个隧道的基础上实例化包过滤器或快速模式选择器。
As described in [17], a number of issues arise when forwarding DHCP client requests from untrusted sources. These include DHCP exhaustion attacks, and spoofing of the client identifier option or client MAC address. These issues can be partially addressed through use of the DHCP Relay Information Option [17].
如[17]所述，从不受信任的来源转发DHCP客户端请求时会出现许多问题。这些攻击包括DHCP耗尽攻击，以及欺骗客户端标识符选项或客户端MAC地址。这些问题可以通过使用DHCP中继信息选项部分解决[17]。
This document requires that an htype value be allocated for use with IPsec tunnel mode, as described in section 4.1. Note that DHCP relies on the arp-parameters registry for definition of both the hrd parameter in ARP and the htype parameter in BOOTP/DHCP. As a result, an assignment in the arp-parameters registry is required, even though IPsec-DHCP will never use that parameter for ARP purposes, since conceptually BOOTP/DHCP and ARP share the arp-parameters registry.
如第4.1节所述，本文档要求为IPsec隧道模式分配一个htype值。注意，DHCP依赖arp参数注册表来定义arp中的hrd参数和BOOTP/DHCP中的htype参数。因此，需要在arp参数注册表中进行分配，即使IPsec DHCP永远不会将该参数用于arp目的，因为概念上BOOTP/DHCP和arp共享arp参数注册表。
This document does not create any new number spaces for IANA administration.
本文档不会为IANA管理创建任何新的数字空间。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[2] Atkinson，R.和S.Kent，“互联网协议的安全架构”，RFC 2401，1998年11月。
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[3] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[4] Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[5] Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[6] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[7] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[7] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[8] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998.
[8] Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[9] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[10] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[10] McGregor，G.“PPP互联网协议控制协议（IPCP）”，RFC 1332，1992年5月。
[11] Cobb, S., "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses", RFC 1877, December 1995.
[11] Cobb，S.，“名称服务器地址的PPP互联网协议控制协议扩展”，RFC 1877，1995年12月。
[12] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., Rabil, G., Dooley, M. and A. Kapur, "DHCP Failover Protocol", Work in Progress.
[12] Droms，R.，Kinnear，K.，Stapp，M.，Volz，B.，Gonczi，S.，Rabil，G.，Dooley，M.和A.Kapur，“DHCP故障切换协议”，工作正在进行中。
[13] Dukes, D. and R. Pereira, "The ISAKMP Configuration Method", Work in Progress.
[13] Dukes，D.和R.Pereira，“ISAKMP配置方法”，正在进行中。
[14] T'Joens, Y., Hublet, C. and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, December 2001.
[14] T'Joens，Y.，Hublet，C.和P.De Schrijver，“DHCP重新配置扩展”，RFC 3203，2001年12月。
[15] Waters, G., "The IPv4 Subnet Selection Option for DHCP", RFC 3011, November 2000.
[15] Waters，G.，“DHCP的IPv4子网选择选项”，RFC3011，2000年11月。
[16] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, A., Beser, B. and J. Privat, "The User Class Option for DHCP", RFC 3004, November 2000.
[16] Stump，G.，Droms，R.，Gu，Y.，Vyaghrapuri，R.，Demirtjis，A.，Beser，B.和J.Privat，“DHCP的用户类选项”，RFC 30042000年11月。
[17] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[17] Patrick，M.，“DHCP中继代理信息选项”，RFC 3046，2001年1月。
[18] Droms, R., and Lemon, T., The DHCP Handbook, Macmillan, Indianapolis, Indiana, 1999.
[18] Droms，R.和Lemon，T.，DHCP手册，麦克米伦，印第安纳州印第安纳波利斯，1999年。
[19] Volz, B., Gonczi, S., Lemon, T. and R. Stevens, "DHC Load Balancing Algorithm", RFC 3074, February 2001.
[19] Volz，B.，Gonczi，S.，Lemon，T.和R.Stevens，“DHC负载平衡算法”，RFC 3074，2001年2月。
[20] Lemon, T., Cheshire, S. and B. Volz, "The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP)", RFC 3442, December 2002.
[20] Lemon，T.，Cheshire，S.和B.Volz，“动态主机配置协议（DHCP）的无类静态路由选项”，RFC 3442，2002年12月。
[21] Kelly, S. and S. Ramamoorthi, "Requirements for IPsec Remote Access Scenarios", RFC 3457, January 2003.
[21] Kelly，S.和S.Ramamoorthi，“IPsec远程访问场景的要求”，RFC 3457，2003年1月。
[22] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[22] Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，G.de Groot和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[23] Atkinson, R., "Key Exchange Delegation Record for the DNS", RFC 2230, November 1997.
[23] 阿特金森，R.，“DNS的密钥交换委托记录”，RFC 2230，1997年11月。
[24] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[24] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
This document has been enriched by comments from John Richardson and Prakash Iyer of Intel, Gurdeep Pall and Peter Ford of Microsoft.
Intel的John Richardson和Prakash Iyer、微软的Gurdep Pall和Peter Ford的评论丰富了本文档。
Appendix - IKECFG evaluation
附录-IKECFG评估
Alternatives to DHCPv4, such as ISAKMP CFG, described in [13], do not meet the basic requirements described in [21], nor do they provide the additional capabilities of DHCPv4.
DHCPv4的替代品，如[13]中所述的ISAKMP CFG，不满足[21]中所述的基本要求，也不提供DHCPv4的附加功能。
Basic configuration While ISAKMP CFG can provide for IP address assignment as well as configuration of a few additional parameters such as the DNS server and WINS server addresses, the rich configuration facilities of DHCPv4 are not supported. Past experience with similar configuration mechanisms within PPP IPCP [11] has taught us that it is not viable merely to support minimal configuration. Eventually, either much of the functionality embodied in the DHCPv4 options [4] is duplicated or support for DHCPINFORM [3] will be required.
基本配置虽然ISAKMP CFG可以提供IP地址分配以及一些附加参数（如DNS服务器和WINS服务器地址）的配置，但不支持DHCPv4的丰富配置功能。PPP IPCP[11]中类似配置机制的以往经验告诉我们，仅支持最小配置是不可行的。最终，要么复制了DHCPv4选项[4]中包含的大部分功能，要么需要对DHCPInfo[3]的支持。
Address management integration Since IKECFG is not integrated with existing IP address management facilities, it is difficult to integrate it with policy management services that may be dependent on the user to IP address binding.
地址管理集成由于IKECFG未与现有IP地址管理设施集成，因此很难将其与可能依赖于用户到IP地址绑定的策略管理服务集成。
Address pool management IKECFG does not provide a mechanism for the remote host to indicate a preference for a particular address pool. This makes it difficult to support address pool management.
地址池管理IKECFG不提供远程主机指示特定地址池首选项的机制。这使得支持地址池管理变得困难。
Reconfiguration IKECFG does not support the concept of configuration leases or reconfiguration.
重新配置IKECFG不支持配置租用或重新配置的概念。
Fail-over support Since IKECFG creates a separate pool of address state, it complicates the provisioning of network utility-class reliability, both in the IP address management system and in the security gateways themselves.
故障转移支持由于IKECFG创建了一个单独的地址状态池，它使IP地址管理系统和安全网关本身的网络实用程序类可靠性的提供变得复杂。
Security and simplicity As past history with PPP IPCP demonstrates, once it is decided to provide non-integrated address management and configuration facilities within IKE, it will be difficult to limit the duplication of effort to address assignment. Instead, it will be tempting to also duplicate the configuration, authentication and fail-over facilities of DHCPv4. This duplication will greatly increase the scope of work, eventually compromising the security of IKE.
安全性和简单性——PPP IPCP的历史表明，一旦决定在IKE内提供非集成地址管理和配置设施，就很难限制地址分配的重复工作。相反，复制DHCPv4的配置、身份验证和故障转移功能也很有诱惑力。这种重复将大大增加工作范围，最终危及IKE的安全性。
Authentication While IKECFG can support mutual authentication of the IPsec tunnel endpoints, it is difficult to integrate IKECFG with DHCPv4 authentication [5]. This is because the security gateway will not typically have access to the client credentials necessary to issue an DHCPv4 authentication option on the client's behalf.
身份验证虽然IKECFG可以支持IPsec隧道端点的相互身份验证，但很难将IKECFG与DHCPv4身份验证集成[5]。这是因为安全网关通常无法访问代表客户端发出DHCPv4身份验证选项所需的客户端凭据。
As a result, security gateways implementing IKECFG typically request allocation of an IP address on their own behalf, and then assign this to the client via IKECFG. Since IKECFG does not support the concept of an address lease, the security gateway will need to do the renewal itself. This complicates the renewal process.
因此，实现IKECFG的安全网关通常代表自己请求分配IP地址，然后通过IKECFG将其分配给客户端。由于IKECFG不支持地址租赁的概念，安全网关将需要自己进行更新。这使更新过程复杂化。
Since RFC 2131 [3] assumes that a DHCPREQUEST will not contain a filled in giaddr field when generated during RENEWING state, the DHCPACK will be sent directly to the client, which will not be expecting it. As a result, it is either necessary for the security gateway to add special code to avoid forwarding such packets, or to wait until REBINDING state. Since [3] does not specify that the giaddr field cannot be filled in when in the REBINDING state, the security gateway may put its own address in the giaddr field when in REBINDING state, thereby ensuring that it can receive the renewal response without treating it as a special case.
由于RFC 2131[3]假设在续订状态期间生成DHCPREQUEST时，DHCPREQUEST将不包含已填充的giaddr字段，因此DHCPACK将直接发送到客户端，而客户端并不期望它。因此，安全网关有必要添加特殊代码以避免转发此类数据包，或者等待重新绑定状态。由于[3]未规定处于重新绑定状态时无法填写giaddr字段，因此安全网关在处于重新绑定状态时可以将其自己的地址放入giaddr字段，从而确保其可以接收续订响应，而无需将其视为特例。
Authors' Addresses
作者地址
Baiju V. Patel Intel Corp 2511 NE 25th Ave Hillsboro, OR 97124
Baiju诉帕特尔英特尔公司案希尔斯博罗东北25大道2511号，或97124
Phone: +1 503 712 2303
EMail: baiju.v.patel@intel.com
Phone: +1 503 712 2303
EMail: baiju.v.patel@intel.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 706 6605
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
EMail: bernarda@microsoft.com
Scott Kelly Airespace 110 Nortech Pkwy San Jose CA 95134 USA
Scott Kelly Airespace 110 Nortech Pkwy加利福尼亚州圣何塞95134美国
Phone: +1 (408) 941-0500
EMail: scott@hyperthought.com
Phone: +1 (408) 941-0500
EMail: scott@hyperthought.com
Vipul Gupta Sun Microsystems, Inc. MS UMTV29-235 2600 Casey Avenue Mountain View, CA 94303
Vipul Gupta Sun Microsystems，Inc.加利福尼亚州凯西大道山景城2600号UMTV29-235邮编94303
Phone: +1 650 336 1681
EMail: vipul.gupta@sun.com
Phone: +1 650 336 1681
EMail: vipul.gupta@sun.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。