diff options
Diffstat (limited to 'doc/rfc/rfc7341.txt')
| -rw-r--r-- | doc/rfc/rfc7341.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc7341.txt b/doc/rfc/rfc7341.txt new file mode 100644 index 0000000..82e4f18 --- /dev/null +++ b/doc/rfc/rfc7341.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) Q. Sun +Request for Comments: 7341 Y. Cui +Category: Standards Track Tsinghua University +ISSN: 2070-1721 M. Siodelski + ISC + S. Krishnan + Ericsson + I. Farrer + Deutsche Telekom AG + August 2014 + + + DHCPv4-over-DHCPv6 (DHCP 4o6) Transport + +Abstract + + IPv4 connectivity is still needed as networks migrate towards IPv6. + Users require IPv4 configuration even if the uplink to their service + provider supports IPv6 only. This document describes a mechanism for + obtaining IPv4 configuration information dynamically in IPv6 networks + by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 + messages and two new DHCPv6 options are defined for this purpose. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7341. + + + + + + + + + + + + + + + +Sun, et al. Standards Track [Page 1] + +RFC 7341 DHCPv4 over DHCPv6 August 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Requirements Language ...........................................3 + 3. Terminology .....................................................3 + 4. Applicability ...................................................4 + 5. Architecture Overview ...........................................4 + 6. New DHCPv6 Messages .............................................6 + 6.1. Message Types ..............................................6 + 6.2. Message Formats ............................................6 + 6.3. DHCPv4-query Message Flags .................................7 + 6.4. DHCPv4-response Message Flags ..............................7 + 7. New DHCPv6 Options ..............................................7 + 7.1. DHCPv4 Message Option Format ...............................7 + 7.2. DHCP 4o6 Server Address Option Format ......................8 + 8. Use of the DHCPv4-query Unicast Flag ............................9 + 9. DHCP 4o6 Client Behavior .......................................10 + 10. Relay Agent Behavior ..........................................12 + 11. DHCP 4o6 Server Behavior ......................................12 + 12. Security Considerations .......................................13 + 13. IANA Considerations ...........................................14 + 14. Contributors List .............................................14 + 15. References ....................................................14 + 15.1. Normative References .....................................14 + 15.2. Informative References ...................................15 + + + + + + + + + + + +Sun, et al. Standards Track [Page 2] + +RFC 7341 DHCPv4 over DHCPv6 August 2014 + + +1. Introduction + + As the migration towards IPv6 continues, IPv6-only networks will + become more prevalent. In such networks, IPv4 connectivity will + continue to be provided as a service over IPv6-only networks. In + addition to provisioning IPv4 addresses for clients of this service, + other IPv4 configuration parameters may also be needed (e.g., + addresses of IPv4-only services). + + This document describes a transport mechanism to carry DHCPv4 + messages using the DHCPv6 protocol for the dynamic provisioning of + IPv4 addresses and other DHCPv4 specific configuration parameters + across IPv6-only networks. It leverages the existing DHCPv4 + infrastructure, e.g., failover, DNS updates, DHCP Leasequery, etc. + + When IPv6 multicast is used to transport DHCP 4o6 messages, another + benefit is that the operator can gain information about the + underlying IPv6 network to which the DHCP 4o6 client is connected + from the DHCPv6 relay agents through which the request has passed. + +2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Terminology + + This document makes use of the following terms: + + CPE: + Customer Premises Equipment (also known as Customer Provided + Equipment), which provides access for devices connected to a Local + Area Network (LAN), typically at the customer's site/home, to the + Internet Service Provider's (ISP's) network. + + DHCP 4o6 client (or client): + A DHCP client supporting both the DHCPv6 protocol [RFC3315] as + well as the DHCPv4 over DHCPv6 protocol described in this + document. Such a client is capable of requesting IPv6 + configuration using DHCPv6 and IPv4 configuration using DHCPv4 + over DHCPv6. + + DHCP 4o6 server (or server): + A DHCP server that is capable of processing DHCPv4 packets + encapsulated in the DHCPv4 Message option (defined below). + + + + + +Sun, et al. Standards Track [Page 3] + +RFC 7341 DHCPv4 over DHCPv6 August 2014 + + + DHCPv4 over DHCPv6: + A protocol (described in this document) used to carry DHCPv4 + messages in the payload of DHCPv6 messages. + +4. Applicability + + The mechanism described in this document is not universally + applicable. This is intended as a special-purpose mechanism that + will be implemented on nodes that must obtain IPv4 configuration + information using DHCPv4 in specific environments where native DHCPv4 + is not available. Such nodes are expected to follow the advice in + Section 9; nodes that do not require this functionality are expected + not to implement it, or not to enable it by default. This mechanism + may be enabled using an administrative control, or it may be enabled + automatically in accordance with the needs of some dual-stack + transition mechanism such as [LW4OVER6]. Such mechanisms are beyond + the scope of this document. + +5. Architecture Overview + + The architecture described here addresses a typical use case, where a + DHCP client's uplink supports IPv6 only and the Service Provider's + network supports IPv6 and limited IPv4 services. In this scenario, + the client can only use the IPv6 network to access IPv4 services, so + IPv4 services must be configured using IPv6 as the underlying network + protocol. + + Although the purpose of this document is to address the problem of + communication between the DHCPv4 client and the DHCPv4 server, the + mechanism that it describes does not restrict the transported + messages types to DHCPv4 only. As the DHCPv4 message is a special + type of BOOTP message, BOOTP messages [RFC951] MAY also be + transported using the same mechanism. + + DHCP clients may be running on CPE devices, end hosts, or any other + device that supports the DHCP-client function. This document uses + the CPE as an example for describing the mechanism. This does not + preclude any end host, or other device requiring IPv4 configuration, + from implementing DHCPv4 over DHCPv6 in the future. + + This mechanism works by carrying DHCPv4 messages encapsulated within + the newly defined DHCPv6 messages. The DHCPv6-relay encapsulation is + used solely to deliver DHCPv4 packets to a DHCPv4-capable server, and + does not allocate any IPv6 addresses nor does it provide + IPv6-configuration information to the client. Figure 1, below, + illustrates one possible deployment architecture of this mechanism. + + + + + +Sun, et al. Standards Track [Page 4] + +RFC 7341 DHCPv4 over DHCPv6 August 2014 + + + The DHCP 4o6 client implements a new DHCPv6 message called + DHCPv4-query, which carries a DHCPv4 message encapsulated in the new + DHCPv4 Message option. The DHCPv6 message can be transmitted either + via DHCPv6 Relay Agents or directly to the DHCP 4o6 server. + + The server replies with a new DHCPv6 message called DHCPv4-response, + which carries the DHCPv4 message from the server, encapsulated in the + DHCPv4 Message option. + + _____________ _____________ + / \ / \ + | | | | + +--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+ + | DHCP 4o6 | Network | DHCPv6 | Network | DHCP 4o6 | + | Client +---------+ Relay Agent +---------+ Server | + | (on CPE) | | | | | + +--------+-+ +-+-----------+-+ +-+--------+ + | | | | + \_____________/ \_____________/ + + + Figure 1: Architecture Overview + + Before the client can use DHCPv4 over DHCPv6, it MUST obtain the + necessary IPv6 configuration. The client requests the DHCP 4o6 + Server Address option from the server by sending the option code in + an Option Request option as described in [RFC3315]. If the server + responds with the DHCP 4o6 Server Address option, it is an indication + to the client to attempt using DHCPv4 over DHCPv6 to obtain IPv4 + configuration. Otherwise, the client MUST NOT use DHCPv4 over DHCPv6 + to request IPv4 configuration. + + The client obtains the address(es) of the DHCP 4o6 server(s) from the + DHCP 4o6 Server Address option and uses it (them) to communicate with + the DHCP 4o6 servers as described in Section 9. If the DHCP 4o6 + Server Address option contains no addresses (is empty), the client + uses the well-known All_DHCP_Relay_Agents_and_Servers multicast + address to communicate with the DHCP 4o6 server(s). + + Before applying for an IPv4 address via a DHCPv4-query message, the + client must identify a suitable network interface for the address. + Once the request is acknowledged by the server, the client can + configure the address and other relevant parameters on this + interface. The mechanism for determining a suitable interface is out + of the scope of the document. + + + + + + +Sun, et al. Standards Track [Page 5] + +RFC 7341 DHCPv4 over DHCPv6 August 2014 + + +6. New DHCPv6 Messages + + Two new DHCPv6 messages carry DHCPv4 messages between the client and + the server using the DHCPv6 protocol: DHCPv4-query and + DHCPv4-response. This section describes the structures of these + messages. + +6.1. Message Types + + DHCPV4-QUERY (20): The DHCP 4o6 client sends a DHCPv4-query message + to a DHCP 4o6 server. The DHCPv4 Message option carried by this + message contains a DHCPv4 message that the DHCP 4o6 client uses to + request IPv4 configuration parameters from the server. + + DHCPV4-RESPONSE (21): A DHCP 4o6 server sends a DHCPv4-response + message to a DHCP 4o6 client. It contains a DHCPv4 Message option + carrying a DHCPv4 message in response to a DHCPv4 message received + by the server in the DHCPv4 Message option of the DHCPv4-query + message. + +6.2. Message Formats + + Both DHCPv6 messages defined in this document share the following + format: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | msg-type | flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . options . + . (variable) . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: The Format of DHCPv4-query and DHCPv4-response Messages + + msg-type: Identifies the message type. It can be either + DHCPV4-QUERY (20) or DHCPV4-RESPONSE (21) corresponding to the + contained DHCPv4-query or DHCPv4-response, respectively. + + flags: Specifies flags providing additional information required by + the server to process the DHCPv4 message encapsulated in the + DHCPv4-query message, or required by the client to process a + DHCPv4 message encapsulated in the DHCPv4-response message. + + + + + +Sun, et al. Standards Track [Page 6] + +RFC 7341 DHCPv4 over DHCPv6 August 2014 + + + options: Options carried by the message. The DHCPv4 Message Option + (described in Section 7.1) MUST be carried by the message. Only + DHCPv6 options for IPv4 configuration may be included in this + field. It MUST NOT contain DHCPv6 options related solely to IPv6, + or IPv6-only service configuration. + +6.3. DHCPv4-query Message Flags + + The "flags" field of the DHCPv4-query is used to carry additional + information that may be used by the server to process the + encapsulated DHCPv4 message. Currently, only one bit of this field + is used. Remaining bits are reserved for the future use. The + "flags" field has the following format: + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |U| MBZ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: DHCPv4-query Flags Format + + U: Unicast flag. If set to 1, it indicates that the DHCPv4 message + encapsulated within the DHCPv4-query message would be sent to a + unicast address if it were sent using IPv4. If this flag is set + to 0, it indicates that the DHCPv4 message would be sent to the + broadcast address if it were sent using IPv4. The usage of the + flag is described in detail in Section 8. + + MBZ: Bits MUST be set to zero when sending and MUST be ignored when + receiving. + +6.4. DHCPv4-response Message Flags + + This document introduces no flags to be carried in the "flags" field + of the DHCPv4-response message. They are all reserved for future + use. The DHCP 4o6 server MUST set all bits of this field to 0 and + the DHCP 4o6 client MUST ignore the content in this field. + +7. New DHCPv6 Options + +7.1. DHCPv4 Message Option Format + + The DHCPv4 Message option carries a DHCPv4 message that is sent by + the client or the server. Such messages exclude any IP or UDP + headers. + + + + + +Sun, et al. Standards Track [Page 7] + +RFC 7341 DHCPv4 over DHCPv6 August 2014 + + + The format of the DHCPv4 Message option is: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | option-code | option-len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . DHCPv4-message . + . . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: DHCPv4 Message Option Format + + option-code: OPTION_DHCPV4_MSG (87). + + option-len: Length of the DHCPv4 message. + + DHCPv4-message: The DHCPv4 message sent by the client or the server. + In a DHCPv4-query message, it contains a DHCPv4 message sent by a + client. In a DHCPv4-response message, it contains a DHCPv4 + message sent by a server in response to a client. + +7.2. DHCP 4o6 Server Address Option Format + + The DHCP 4o6 Server Address option is sent by a server to a client + requesting IPv6 configuration using DHCPv6 [RFC3315]. It carries a + list of DHCP 4o6 servers' IPv6 addresses that the client should + contact to obtain IPv4 configuration. This list may include + multicast and unicast addresses. The client sends its requests to + all unique addresses carried in this option. + + This option may also carry no IPv6 addresses, which instructs the + client to use the All_DHCP_Relay_Agents_and_Servers multicast address + as the destination address. + + The presence of this option in the server's response indicates to the + client that it should use DHCPv4 over DHCPv6 to obtain IPv4 + configuration. If the option is absent, the client MUST NOT enable + DHCPv4-over-DHCPv6 functionality. + + + + + + + + + + +Sun, et al. Standards Track [Page 8] + +RFC 7341 DHCPv4 over DHCPv6 August 2014 + + + The format of the DHCP 4o6 Server Address option is: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | option-code | option-len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . IPv6 Address(es) . + . . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: DHCP 4o6 Servers Address Option Format + + option-code: OPTION_DHCP4_O_DHCP6_SERVER (88). + + option-len: Length of the IPv6 address(es) carried by the option, + i.e., multiple of 16 octets. Minimal length of this option is 0. + + IPv6 Address: Zero or more IPv6 addresses of the DHCP 4o6 server(s). + +8. Use of the DHCPv4-query Unicast Flag + + A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST + message to either a broadcast or unicast address depending on its + state. For example, a client in the RENEWING state uses a unicast + address to contact the DHCPv4 server to renew its lease. A client in + the REBINDING state uses a broadcast address. + + In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the + DHCP 4o6 server. There is no relation between the outer IPv6 address + and the inner DHCPv4 message. As a result, the server is unable to + determine whether the received DHCPv4 messages should have been sent + using broadcast or unicast in IPv4 by checking the IPv6 address. + + In order to allow the server to determine the client's state, the + Unicast flag is carried in the DHCPv4-query message. The client MUST + set this flag to 1 when the DHCPv4 message would have been sent to + the unicast address if using DHCPv4 over IPv4. This flag MUST be set + to 0 if the DHCPv4 client would have sent the message to the + broadcast address in IPv4. The choice whether a given message should + be sent to a broadcast or unicast address is made based on the + [RFC2131] and its extensions. + + Note: The Unicast flag reflects how the DHCPv4 packet would have been + sent; not how the DHCPv6 packet itself is sent. + + + + +Sun, et al. Standards Track [Page 9] + +RFC 7341 DHCPv4 over DHCPv6 August 2014 + + +9. DHCP 4o6 Client Behavior + + The client MUST obtain necessary IPv6 configuration from a DHCPv6 + server before using DHCPv4 over DHCPv6. The client requests the DHCP + 4o6 Server Address option using the Option Request option (ORO) in + every Solicit, Request, Renew, Rebind, and Information-request + message. If the DHCPv6 server includes the DHCP 4o6 Server Address + option in its response, it is an indication that the client can use + DHCPv4 over DHCPv6 to obtain the IPv4 configuration (by sending + DHCPv4 messages encapsulated in DHCPv4-query messages). + + The client MUST NOT use DHCPv4 over DHCPv6 to request IPv4 + configuration if the DHCPv6 server does not include the DHCP 4o6 + Server Address option. If the IPv6 configuration that contained the + DHCP 4o6 Server Address option subsequently expires, or if the + renewed IPv6 configuration does not contain the DHCP 4o6 Server + Address option, the client MUST stop using DHCPv4 over DHCPv6 to + request or renew IPv4 configuration. However, the client continues + to request DHCP 4o6 Server Address option in the messages sent to the + DHCPv6 server as long as it desires to use DHCPv4 over DHCPv6. + + It is possible in a multihomed configuration for there to be more + than one DHCPv6 configuration containing a DHCP 4o6 Server Address + Option active at the same time. In this case, the configurations are + treated as being independent, so that when any such configuration is + active, a DHCPv4-over-DHCPv6 function may be enabled for that + configuration. + + An implementation may also treat such configurations as being + exclusive, such that only one is kept active at a time. In this + case, the client keeps the same configuration active continuously as + long as it is valid. If that configuration becomes invalid but one + or more other configurations remain valid, the client activates one + of the remaining valid configurations. + + Which strategy to follow is dependent on the implementation: keeping + multiple configurations active at the same time may provide useful + redundancy in some applications but may be needlessly complex in + other cases. + + If the client receives the DHCP 4o6 Server Address option and DHCPv4 + [RFC2131] is used on the interface over which the DHCPv6 option was + received, the client MUST stop using the IPv4 configuration received + using DHCPv4 on this interface. The client MAY send a DHCPRELEASE to + the DHCPv4 server to relinquish an existing lease as described in + Section 4.4.6 of [RFC2131]. The client MUST NOT use DHCPv4 on this + interface as long as it receives DHCP 4o6 Server Address option in + the messages received from the DHCPv6 server. + + + +Sun, et al. Standards Track [Page 10] + +RFC 7341 DHCPv4 over DHCPv6 August 2014 + + + If the client receives a DHCP 4o6 Server Address option that contains + no IP addresses, i.e., the option is empty, the client MUST send its + requests to the All_DHCP_Relay_Agents_and_Servers multicast address. + If there is a list of IP addresses in the option, the client SHOULD + send requests to each unique address carried by the option. + + If the client obtained stateless IPv6 configuration by sending an + Information-request message to the server, the client MUST follow the + rules in [RFC4242] to periodically refresh the DHCPv4-over-DHCPv6 + configuration (i.e., list of DHCP 4o6 servers) as well as other + configuration data. The client that obtained stateful IPv6 + configuration will refresh the status of DHCPv4-over-DHCPv6 function + when extending a lifetime of acquired IPv6 address (Renew and Rebind + messages). + + The client MUST employ an IPv6 address of an appropriate scope from + which to source the DHCPv4-query message. When the client sends a + DHCPv4-query message to the multicast address, it MUST use a link- + local address as the source address as described in [RFC3315]. When + the client sends a DHCPv4-query message using unicast, the source + address MUST be an address of appropriate scope, acquired in advance. + + The client generates a DHCPv4 message and stores it verbatim in the + DHCPv4 Message option carried by the DHCPv4-query message. The + client MUST put exactly one DHCPv4 Message option into a single + DHCPv4-query message. The client MUST NOT request the DHCP 4o6 + Server Address option in the DHCPv4-query message. + + The client MUST follow the rules defined in Section 8 when setting + the Unicast flag based on the DHCPv4 destination. + + On receiving a DHCPv4-response message, the client MUST look for the + DHCPv4 Message option within this message. If this option is not + found, the DHCPv4-response message is discarded. If the DHCPv4 + Message option is present, the client extracts the DHCPv4 message it + contains and processes it as described in Section 4.4 of [RFC2131]. + + When dealing with IPv4 configuration, the client MUST follow the + normal DHCPv4 retransmission requirements and strategy as specified + in Section 4.1 of [RFC2131]. There are no explicit transmission + parameters associated with a DHCPv4-query message, as this is + governed by the DHCPv4 "state machine" [RFC2131]. + + The client MUST implement [RFC4361] to ensure that the device + correctly identifies itself. It MUST send a 'client identifier' + option when using DHCPv4 over DHCPv6. + + + + + +Sun, et al. Standards Track [Page 11] + +RFC 7341 DHCPv4 over DHCPv6 August 2014 + + +10. Relay Agent Behavior + + When a DHCPv6 relay agent receives a DHCPv4-query message, it may not + recognize this message. The unknown message MUST be forwarded as + described in [RFC7283]. + + A DHCPv6 relay agent that can recognize DHCP 4o6 messages MAY allow + the configuration of a separate set of destination addresses for such + messages in addition to the destination addresses used for relaying + the other DHCPv6 messages. To implement this function, the relay + checks the received DHCPv6 message type and forwards according to the + following logic: + + 1. If the message type is DHCPV4-QUERY, the packet is relayed to the + configured DHCP 4o6 Server's address(es) in the form of a normal + DHCPv6 packet (i.e., DHCPv6/UDP/IPv6). + + 2. For any other DHCPv6 message type, forward according to section + 20 of [RFC3315]. + + The above logic only allows for separate relay destinations + configured on the relay agent closest to the client (single relay + hop). Multiple relaying hops are not considered in the case of + separate relay destinations. + +11. DHCP 4o6 Server Behavior + + When the server receives a DHCPv4-query message from a client, it + searches for the DHCPv4 Message option. The server discards a packet + without this option. In addition, the server MAY notify an + administrator about the receipt of this malformed packet. The + mechanism for this notification is out of scope for this document. + + If the server finds a valid DHCPv4 Message option, it extracts the + original DHCPv4 message. Since the DHCPv4 message is encapsulated in + the DHCPv6 message, it lacks the information that is typically used + by the DHCPv4 server, implementing [RFC2131], to make address- + allocation decisions, e.g., giaddr for relayed messages and IPv4 + address of the interface that the server is using to communicate with + a directly connected client. Therefore, the DHCP 4o6 server + allocates addresses according to the policies on local address + assignment determined by the server administrator. For example, if + the DHCPv4-query message has been sent via a relay, the server MAY + use the link-address field of the Relay-forward message as a lookup + for the IPv4 subnet from which to assign a DHCPv4 address. If the + DHCPv4-query message has been sent from a directly connected client, + + + + + +Sun, et al. Standards Track [Page 12] + +RFC 7341 DHCPv4 over DHCPv6 August 2014 + + + the server MAY use the IPv6 source address of the message to + determine the appropriate IPv4 subnet to use for DHCPv4 address + assignment. + + Alternatively, the server may act as a DHCPv4 relay agent and forward + the DHCPv4 packet to a "normal" DHCPv4 server. The details of such a + solution have not been considered by the working group; describing + that solution is out of scope of this document and is left as future + work should the need for it arise. + + The server SHOULD use the "flags" field of the DHCPv4-query message + to create a response (server to client DHCPv4 message). The use of + this field is described in detail in Section 8. + + When an appropriate DHCPv4 response is created, the server places it + in the payload of a DHCPv4 Message option, which it puts into the + DHCPv4-response message. + + If the DHCPv4-query message was received directly by the server, the + DHCPv4-response message MUST be unicast from the interface on which + the original message was received. + + If the DHCPv4-query message was received in a Relay-forward message, + the server creates a Relay-reply message with the DHCPv4-response + message in the payload of a Relay Message option, and responds as + described in Section 20.3 of [RFC3315]. + +12. Security Considerations + + In this specification, DHCPv4 messages are encapsulated in the newly + defined option and messages. This is similar to the handling of the + current relay agent messages. In order to bypass firewalls or + network authentication gateways, a malicious attacker may leverage + this feature to convey other messages using DHCPv6, i.e., use DHCPv6 + as a form of encapsulation. However, the potential risk from this is + no more severe than that with the current DHCPv4 and DHCPv6 practice. + + It is possible for a rogue server to reply with a DHCP 4o6 Server + Address option containing duplicated IPv6 addresses, which could + cause an amplification attack. To avoid this, the client MUST check + if there are duplicate IPv6 addresses in a DHCP 4o6 Server Address + option when receiving one. The client MUST ignore any but the first + instance of each address. + + When considering whether to enable DHCPv4-over-DHCPv6, one important + consideration is that when it is enabled, this gives the DHCPv6 + server the ability to shut off DHCPv4 traffic, and, consequently, + IPv4 traffic, on the interface that is configured to do DHCPv4-over- + + + +Sun, et al. Standards Track [Page 13] + +RFC 7341 DHCPv4 over DHCPv6 August 2014 + + + DHCPv6. For this reason, DHCPv4-over-DHCPv6 should only be enabled + in situations where there is a clear trust relationship that + eliminates this concern. For instance, a CPE device can safely + enable this on its WAN interface, because it is reasonable to assume + that an ISP will not accidentally configure DHCPv4 over DHCPv6 + service on that link, and that it will be impractical for an attacker + to set up a rogue DHCPv6 server in the ISP's network. + +13. IANA Considerations + + IANA has allocated two DHCPv6 option codes for use by + OPTION_DHCPV4_MSG (87) and OPTION_DHCP4_O_DHCP6_SERVER (88) from the + "Option Codes" table. Also, IANA has allocated two DHCPv6 message + type codes for the DHCPV4-QUERY (20) and DHCPV4-RESPONSE (21) from + the "Message Types" table of the "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)" registry. Both tables can be found at + <http://www.iana.org/assignments/dhcpv6-parameters/>. + +14. Contributors List + + Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Cong Liu, and + Yuchi Chen for their great contributions to the specification. + +15. References + +15.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC + 2131, March 1997. + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh + Time Option for Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 4242, November 2005. + + [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client + Identifiers for Dynamic Host Configuration Protocol + Version Four (DHCPv4)", RFC 4361, February 2006. + + [RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 + Messages", RFC 7283, July 2014. + + + + +Sun, et al. Standards Track [Page 14] + +RFC 7341 DHCPv4 over DHCPv6 August 2014 + + +15.2. Informative References + + [LW4OVER6] + Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. + Farrer, "Lightweight 4over6: An Extension to the DS-Lite + Architecture", Work in Progress, June 2014. + + [RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, + September 1985. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sun, et al. Standards Track [Page 15] + +RFC 7341 DHCPv4 over DHCPv6 August 2014 + + +Authors' Addresses + + Qi Sun + Tsinghua University + Beijing 100084 + P.R. China + + Phone: +86-10-6278-5822 + EMail: sunqi@csnet1.cs.tsinghua.edu.cn + + + Yong Cui + Tsinghua University + Beijing 100084 + P.R. China + + Phone: +86-10-6260-3059 + EMail: yong@csnet1.cs.tsinghua.edu.cn + + + Marcin Siodelski + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: msiodelski@gmail.com + + + Suresh Krishnan + Ericsson + 8400 Blvd. Decarie + Town of Mount Royal, Quebec + Canada + + EMail: suresh.krishnan@ericsson.com + + + Ian Farrer + Deutsche Telekom AG + CTO-ATI, Landgrabenweg 151 + Bonn, NRW 53227 + Germany + + EMail: ian.farrer@telekom.de + + + + + + +Sun, et al. Standards Track [Page 16] + |