draft-ietf-dhc-dhcpv4-over-dhcpv6-03.txt   draft-ietf-dhc-dhcpv4-over-dhcpv6-04.txt 
DHC Working Group Q. Sun DHC Working Group Q. Sun
Internet-Draft Y. Cui Internet-Draft Y. Cui
Intended status: Standards Track Tsinghua University Intended status: Standards Track Tsinghua University
Expires: May 26, 2014 M. Siodelski Expires: July 20, 2014 M. Siodelski
ISC ISC
S. Krishnan S. Krishnan
Ericsson Ericsson
I. Farrer I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
November 22, 2013 January 16, 2014
DHCPv4 over DHCPv6 Transport DHCPv4 over DHCPv6 Transport
draft-ietf-dhc-dhcpv4-over-dhcpv6-03 draft-ietf-dhc-dhcpv4-over-dhcpv6-04
Abstract Abstract
IPv4 connectivity is still needed as networks migrate towards IPv6. IPv4 connectivity is still needed as networks migrate towards IPv6.
Users require IPv4 configuration even if the uplink to their service Users require IPv4 configuration even if the uplink to their service
provider supports IPv6 only. This document describes a mechanism for provider supports IPv6 only. This document describes a mechanism for
obtaining IPv4 configuration information dynamically in IPv6 networks obtaining IPv4 configuration information dynamically in IPv6 networks
by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6
messages as well as new DHCPv6 options are defined for the purpose of messages and two new DHCPv6 options are defined for this purpose.
conveying DHCPv4 messages through IPv6 networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 26, 2014. This Internet-Draft will expire on July 20, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 22 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3
5. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 5 5. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 5
5.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Message Formats . . . . . . . . . . . . . . . . . . . . . 5 5.2. Message Formats . . . . . . . . . . . . . . . . . . . . . 5
5.3. Boot-request-v6 Message Flags . . . . . . . . . . . . . . 6 5.3. DHCPv4-query Message Flags . . . . . . . . . . . . . . . 6
5.4. Boot-reply-v6 Message Flags . . . . . . . . . . . . . . . 6 5.4. DHCPv4-response Message Flags . . . . . . . . . . . . . . 7
6. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 7 6. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 7
6.1. BOOTP Message Option Format . . . . . . . . . . . . . . . 7 6.1. DHCPv4 Message Option Format . . . . . . . . . . . . . . 7
6.2. DHCPv4-over-DHCPv6 Enable Option Format . . . . . . . . . 7 6.2. 4o6 Server Address Option Format . . . . . . . . . . . . 8
6.3. 4o6 Server Address Option Format . . . . . . . . . . . . 8 7. Use of the DHCPv4-query Unicast Flag . . . . . . . . . . . . 8
7. Use of the Boot-request-v6 Unicast Flag . . . . . . . . . . . 8 8. DHCP 4o6 Client Behavior . . . . . . . . . . . . . . . . . . 9
8. 4o6 DHCP Client Behavior . . . . . . . . . . . . . . . . . . 9 9. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 11
9. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 10 10. DHCP 4o6 Server Behavior . . . . . . . . . . . . . . . . . . 11
10. 4o6 DHCP Server Behavior . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
13. Contributors List . . . . . . . . . . . . . . . . . . . . . . 12 13. Contributors List . . . . . . . . . . . . . . . . . . . . . . 12
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
14.1. Normative References . . . . . . . . . . . . . . . . . . 12 14.1. Normative References . . . . . . . . . . . . . . . . . . 13
14.2. Informative References . . . . . . . . . . . . . . . . . 13 14.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
As the migration towards IPv6 continues, IPv6-only networks will As the migration towards IPv6 continues, IPv6-only networks will
become more prevalent. At the same time, IPv4 connectivity will become more prevalent. In such networks, IPv4 connectivity will
continue to be provided as a service over IPv6-only networks. In continue to be provided as a service over IPv6-only networks. In
addition to providing IPv4 addresses for clients of this service, addition to provisioning IPv4 addresses for clients of this service,
other IPv4 configuration parameters may also need to be provided other IPv4 configuration parameters may also be needed (e.g.
(e.g. addresses of IPv4-only services). addresses of IPv4-only services).
This document describes a transport mechanism to carry DHCPv4 This document describes a transport mechanism to carry DHCPv4
messages using DHCPv6 protocol, for the dynamic provisioning of IPv4 messages using the DHCPv6 protocol for the dynamic provisioning of
addresses and other DHCPv4 specific configuration parameters across IPv4 addresses and other DHCPv4 specific configuration parameters
IPv6-only networks. It leverages the existing infrastructure for across IPv6-only networks. It leverages the existing DHCPv4
DHCPv4, e.g. failover, DNS updates, leasequery, etc. infrastructure, e.g. failover, DNS updates, DHCP leasequery, etc.
When IPv6 multicast is used to transport 4o6 messages, another
benefit is that the operator can gain information about the
underlying IPv6 network the 4o6 client is connected to from the the
DHCPv6 relay agents the request has passed through.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
This document makes use of the following terms: This document makes use of the following terms:
4o6 DHCP Client: A DHCP client which supports both DHCPv6 DHCP 4o6 Client: A DHCP client supporting both the DHCPv6 protocol
protocol [RFC3315] as well as the DHCPv4 over [RFC3315] as well as the DHCPv4 over DHCPv6
DHCPv6 protocol described in this document. protocol described in this document. Such a
Such a client is capable to request its IPv6 client is capable of requesting IPv6
configuration using DHCPv6 and IPv4 configuration using DHCPv6 and IPv4 configuration
configuration using DHCPv4 over DHCPv6. using DHCPv4 over DHCPv6.
4o6 DHCP Server: A DHCP server that is capable of processing DHCP 4o6 Server: A DHCP server that is capable of processing
DHCPv4 packets encapsulated in the BOOTP DHCPv4 packets encapsulated in the DHCPv4 Message
Message option (defined below). option (defined below).
CPE: Customer Premises Equipment (also known as CPE: Customer Premises Equipment (also known as
Customer Provided Equipment), which provides Customer Provided Equipment), which provides
the access of devices connected to Local Area access for devices connected to a Local Area
Network (typically at customer's site/home) to Network (typically at the customer's site/home)
Internet Service Provider's network. to the Internet Service Provider's network.
DHCPv4 over DHCPv6: A protocol described in this document, which is DHCPv4 over DHCPv6: A protocol described in this document, used to
used to carry DHCPv4 messages in the payload of carry DHCPv4 messages in the payload of DHCPv6
DHCPv6 messages. messages.
4. Architecture Overview 4. Architecture Overview
The architecture described in this document addresses a typical use The architecture described here addresses a typical use case, where a
case, where a DHCP client's uplink supports IPv6 only and the Service DHCP client's uplink supports IPv6 only and the Service Provider's
Provider's network supports IPv6 and limited IPv4 services. In this network supports IPv6 and limited IPv4 services. In this scenario,
scenario, the client can only use the IPv6 network to access IPv4 the client can only use the IPv6 network to access IPv4 services, so
services. So it must configure IPv4 services using IPv6 as the IPv4 services must be configured using IPv6 as the underlying network
underlying network protocol. protocol.
Although the purpose of this document is to address the problem of Although the purpose of this document is to address the problem of
communication between the DHCPv4 client and the DHCPv4 server, the communication between the DHCPv4 client and the DHCPv4 server, the
mechanism that it describes does not restrict the transported mechanism that it describes does not restrict the transported
messages types only to DHCPv4. As the DHCPv4 message is a special messages types to DHCPv4 only. As the DHCPv4 message is a special
type of the BOOTP message, BOOTP messages can also be transported type of BOOTP message, BOOTP messages can also be transported using
using the same mechanism. the same mechanism.
DHCP clients can be running on CPE devices, end hosts or any other DHCP clients may be running on CPE devices, end hosts or any other
device which supports the DHCP client function. At the time of device that supports the DHCP client function. At the time of
writing, DHCP clients on CPE devices are easier to modify compared to writing, DHCP clients on CPE devices are comparatively easier to
those implemented on end hosts. As a result, this document uses the modify than those implemented on end hosts. As a result, this
CPE as an example for describing the mechanism. This does not document uses the CPE as an example for describing the mechanism.
preclude any end-host, or other device requiring IPv4 configuration, This does not preclude any end-host, or other device requiring IPv4
from implementing the mechanism in the future. configuration, from implementing DHCPv4 over DHCPv6 in the future.
This mechanism works by carrying DHCPv4 messages encapsulated within This mechanism works by carrying DHCPv4 messages encapsulated within
DHCPv6 messages. Figure 1, below, illustrates one possible DHCPv6 messages. Figure 1, below, illustrates one possible
deployment architecture. deployment architecture.
The 4o6 DHCP client implements a new DHCPv6 message called Boot- The DHCP 4o6 client implements a new DHCPv6 message called
request-v6, which contains a new option called BOOTP Message option. DHCPv4-query, which contains a new option called the DHCPv4 Message
The format of this option is described in Section 6.1. option encapsulating a DHCPv4 message sent by the client. The format
of this option is described in Section 6.1.
The DHCPv6 message can be transmitted either via DHCPv6 Relay Agents The DHCPv6 message can be transmitted either via DHCPv6 Relay Agents
or directly to the 4o6 DHCP Server. The server replies with a Boot- or directly to the DHCP 4o6 Server. The server replies with a
reply-v6 message, which is a new DHCPv6 message type. This message DHCPv4-response message, which is a new DHCPv6 message carrying the
carries the DHCPv4 response encapsulated in the BOOTP Message option. DHCPv4 response encapsulated in the DHCPv4 Message option.
_____________ _____________ _____________ _____________
/ \ / \ / \ / \
| | | | | | | |
+--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+ +--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+
| 4o6 DHCP | network | DHCPv6 | network | 4o6 DHCP | | DHCP 4o6 | network | DHCPv6 | network | DHCP 4o6 |
| Client +---------+ Relay Agent +---------+ Server | | Client +---------+ Relay Agent +---------+ Server |
| (on CPE) | | | | | | (on CPE) | | | | |
+--------+-+ +-+-----------+-+ +-+--------+ +--------+-+ +-+-----------+-+ +-+--------+
| | | | | | | |
\_____________/ \_____________/ \_____________/ \_____________/
Figure 1: Architecture Overview Figure 1: Architecture Overview
By default, the DHCPv4-over-DHCPv6 function MUST be disabled on the By default, the DHCPv4-over-DHCPv6 function MUST be disabled on the
client. Before the client can use DHCPv4 over DHCPv6, it MUST obtain client. Before the client can use DHCPv4 over DHCPv6, it MUST obtain
the IPv6 configuration. It requests the DHCPv4-over-DHCPv6 Enable the necessary IPv6 configuration. The client requests the 4o6 Server
option by sending its code in Option Request Option (ORO) described Address option from the DHCPv6 server by sending the option code in
in [RFC3315]. The DHCPv6 server includes the DHCPv4-over-DHCPv6 Option Request option as described in [RFC3315]. If the DHCPv6
Enable option in response to a client's request to instruct the server responds with the 4o6 Server Address option, it is an
client to use DHCPv4 over DHCPv6 for IPv4 configuration. The format indication to the client to attempt using DHCPv4 over DHCPv6 to
of the DHCPv4-over-DHCPv6 Enable option is described in Section 6.2. obtain IPv4 configuration.
Typically, a 4o6 DHCP client communicates with the 4o6 DHCP servers The DHCP 4o6 client obtains the address(es) of the DHCP 4o6 server(s)
using well-known All_DHCP_Relay_Agents_and_Servers multicast address. from the 4o6 Server Address option and uses them to communicate with
the DHCP 4o6 servers as described in Section 8. If the 4o6 Server
Address option contains no addresses (is empty), the DHCP 4o6 client
uses the well-known All_DHCP_Relay_Agents_and_Servers multicast
address to communicate with the DHCP 4o6 server(s).
Client SHOULD request the 4o6 Server Address Option from a DHCPv6 Before applying for an IPv4 address via a DHCPv4-query message, the
server and the server may be configured to respond to the client with DHCP 4o6 client must identify a suitable network interface for the
one such option that contains one or more unicast addresses of the address. Once the request is acknowledged by the DHCP 4o6 server,
4o6 DHCP Servers. The server includes 4o6 Server Address Option in the client can configure the address and other relevant parameters on
Advertise and Reply messages. The format of the option is defined in this interface. The mechanism for determining a suitable interface
Section 6.3. is out of the scope of the document.
5. New DHCPv6 Messages 5. New DHCPv6 Messages
There are two new DHCPv6 messages defined in this document which Two new DHCPv6 messages carry DHCPv4 messages between the client and
carry DHCPv4 messages between a client and a server using DHCPv6 the server using the DHCPv6 protocol: DHCPv4-query and
protocol: Boot-request-v6 and Boot-reply-v6. This section describes DHCPv4-response. This section describes the structures of these
the structures of these messages. messages.
5.1. Message Types 5.1. Message Types
BOOTREQUESTV6 (TBD): Identifies a Boot-request-v6 message. A 4o6 DHCPV4-QUERY (TBD): The DHCP 4o6 client sends a DHCPv4-query
DHCP client sends this message to a 4o6 DHCP message to a DHCP 4o6 server. The DHCPv4
server. The BOOTP Message Option carried by Message option carried by this message
this message contains a BOOTREQUEST message contains a DHCPv4 message that the DHCP 4o6
that the 4o6 DHCP client uses to request IPv4 client uses to request IPv4 configuration
configuration parameters from the server. parameters from the server.
BOOTREPLYV6 (TBD): Identifies a Boot-reply-v6 message. A 4o6 DHCP DHCPv4-RESPONSE (TBD): A DHCP 4o6 server sends a DHCPv4-response
server sends this message to a 4o6 DHCP client. message to a DHCP 4o6 client. It contains a
It contains a BOOTP Message Option carrying a DHCPv4 Message option carrying a DHCPv4
BOOTREPLY message in response to a BOOTREQUEST message in response to a DHCPv4 message
received by the server in the BOOTP Message received by the server in the DHCPv4 Message
Option of the Boot-request-v6 message. option of the DHCPv4-query message.
5.2. Message Formats 5.2. Message Formats
Both DHCPv6 messages defined in this document share the following Both DHCPv6 messages defined in this document share the following
format: format:
0 1 2 3 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 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 | | msg-type | flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. options . . options .
. (variable) . . (variable) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Architecture Overview Figure 2: The format of DHCPv4-query and DHCPv4-response messages
msg-type Identifies message type. It can be either msg-type Identifies the message type. It can be either
BOOTREQUESTV6 (TBD) or BOOTREPLYV6 (TBD) which DHCPV4-QUERY (TBD) or DHCPV4-RESPONSE (TBD)
corresponds to the Boot-request-v6 or Boot-reply-v6, corresponding to the contained DHCPv4-query or
respectively. DHCPv4-response, respectively.
flags Specifies flags which provide additional information flags Specifies flags providing additional information
required by the server to process a DHCPv4 message required by the server to process the DHCPv4 message
encapsulated in Boot-request-v6 message, or required encapsulated in the DHCPv4-query message, or required
by the client to process DHCPv4 message encapsulated by the client to process a DHCPv4 message
in Boot-reply-v6 message. encapsulated in the DHCPv4-response message.
options The options carried by the message. The BOOTP options Options carried by the message. The DHCPv4 Message
Message Option described in Section 6.1 MUST be Option (described in Section 6.1) MUST be carried by
carried by the message. 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.
5.3. Boot-request-v6 Message Flags 5.3. DHCPv4-query Message Flags
The "flags" field of the Boot-request-v6 is used to carry additional The "flags" field of the DHCPv4-query is used to carry additional
information which may be used by the server to process the information that may be used by the server to process the
encapsulated DHCPv4 message. Currently only one bit of this field is encapsulated DHCPv4 message. Currently only one bit of this field is
used. Remaining bits are reserved for the future use. The "flags" used. Remaining bits are reserved for the future use. The "flags"
field has the following format: field has the following format:
0 1 2 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 4 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| Reserved | |U| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Boot-request-v6 flags format Figure 3: DHCPv4-query flags format
U Unicast Flag. If set to 1, it indicates that the U Unicast Flag. If set to 1, it indicates that the
DHCPv4 message encapsulated with the Boot-request-v6 DHCPv4 message encapsulated within the DHCPv4-query
message would be sent to a unicast address if it was message would be sent to a unicast address if it was
sent using IPv4. If this flag is set to 0, it sent using IPv4. If this flag is set to 0, it
indicates that the DHCPv4 message would be sent to indicates that the DHCPv4 message would be sent to
broadcast address if it was sent using IPv4. the broadcast address if it was sent using IPv4.
Reserved Bits reserved for future use. A client that doesn't Reserved Bits MUST be set to zero when sending and MUST be
implement future extensions using these bits MUST set ignored when receiving.
them to 0.
5.4. Boot-reply-v6 Message Flags 5.4. DHCPv4-response Message Flags
This document introduces no flags to be carried in the "flags" field This document introduces no flags to be carried in the "flags" field
of the Boot-reply-v6 message. They are all reserved for the future of the DHCPv4-response message. They are all reserved for the future
use. The 4o6 Server MUST set all bits of this field to 0 and the 4o6 use. The 4o6 Server MUST set all bits of this field to 0 and the 4o6
client MUST ignore the content in this field. client MUST ignore the content in this field.
6. New DHCPv6 Options 6. New DHCPv6 Options
6.1. BOOTP Message Option Format 6.1. DHCPv4 Message Option Format
The BOOTP Message option carries a BOOTP message that is sent by the The DHCPv4 Message option carries a DHCPv4 message that is sent by
client or the server. Such BOOTP messages exclude any IP or UDP the client or the server. Such messages exclude any IP or UDP
headers. headers.
The format of the BOOTP Message Option is: The format of the DHCPv4 Message option is:
0 1 2 3 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 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_BOOTP_MSG | option-len | | OPTION_DHCPV4_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. BOOTP-message . . DHCPv4-message .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: BOOTP Message Option Format Figure 4: DHCPv4 Message option Format
option-code OPTION_BOOTP_MSG (TBD).
option-len Length of BOOTP message.
BOOTP-message The BOOTP message sent by the client or the server.
In a Boot-request-v6 message it contains a
BOOTREQUEST message sent by a client. In a Boot-
reply-v6 message it contains a BOOTREPLY message sent
by a server in response to a client.
6.2. DHCPv4-over-DHCPv6 Enable Option Format
The DHCPv4-over-DHCPv6 Enable option is sent by the DHCPv6-only option-code OPTION_DHCPV4_MSG (TBD).
server to signal that the client SHOULD use DHCPv4 over DHCPv6 to
obtain IPv4 configuration. The server includes this option if it is
requested by the client.
The format of the DHCPv4-over-DHCPv6 Enable option is: option-len Length of the DHCPv4 message.
0 1 2 3 DHCPv4-message The DHCPv4 message sent by the client or the server.
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 In a DHCPv4-query message it contains a DHCPv4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ message sent by a client. In a DHCPv4-response
| OPTION_DHCP4_O_DHCP6_ENABLE | option-len | message it contains a DHCPv4 message sent by a server
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ in response to a client.
Figure 5: DHCPv4-over-DHCPv6 Enable Option Format
option-code OPTION_DHCP4_O_DHCP6_ENABLE (TBD). 6.2. 4o6 Server Address Option Format
option-len 0 The 4o6 Server Address option is sent by the DHCPv6 server to a
client requesting IPv6 configuration. It carries a list of DHCP 4o6
server's IPv6 addresses that the DHCP 4o6 client should contact to
obtain IPv4 configuration. This list may include either multicast or
unicast addresses. The DHCP 4o6 client sends its requests to all
unique addresses carried in this option.
6.3. 4o6 Server Address Option Format 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 4o6 Server Address option carries one or more unicast IPv6 The presence of this option in the DHCPv6 server's response indicates
addresses of the 4o6 DHCP Server(s). The DHCPv6-only server includes to the client that it should use DHCPv4 over DHCPv6 to obtain IPv4
this option if it is requested by the client. configuration. If the option is absent, the client MUST NOT enable
DHCPv4 over DHCPv6 function.
The format of the 4o6 Server Address option is: The format of the 4o6 Server Address option is:
0 1 2 3 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 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_DHCP4_O_DHCP6_SERVER | option-len | | OPTION_DHCP4_O_DHCP6_SERVER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. IPv6 Address(es) . . IPv6 Address(es) .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: 4o6 Servers Address Option Format Figure 5: 4o6 Servers Address Option Format
option-code OPTION_DHCP4_O_DHCP6_SERVER (TBD). option-code OPTION_DHCP4_O_DHCP6_SERVER (TBD).
option-len Length of the IPv6 address(es) carried by the option, option-len Length of the IPv6 address(es) carried by the option,
i.e. multiple of 16 octets. i.e. multiple of 16 octets. Minimal length of this
option is 0.
IPv6 Address One or more IPv6 addresses of the 4o6 DHCP Server(s). IPv6 Address Zero or more IPv6 addresses of the DHCP 4o6
Server(s).
7. Use of the Boot-request-v6 Unicast Flag 7. Use of the DHCPv4-query Unicast Flag
A DHCPv4 client conforming to the [RFC2131] may send its DHCPREQUEST A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST
message to either broadcast or unicast address depending on its message to either a broadcast or unicast address depending on its
state. For example, the client in the RENEWING state uses a unicast state. For example, a client in the RENEWING state uses a unicast
address to contact a DHCPv4 server to renew its lease. The client in address to contact the DHCPv4 server to renew its lease. A client in
the REBINDING state uses a broadcast address. If there is a DHCPv4 the REBINDING state uses a broadcast address. If there is a DHCPv4
relay agent in the middle, a client in the RENEWING state may send a relay agent in the middle, a client in the RENEWING state may send a
DHCPREQUEST message to the unicast address of the relay agent. In DHCPREQUEST message to the unicast address of the relay agent. In
such case the server can't find out whether the client sent a message such a case, the server is unable to determine whether the client
to a unicast or broadcast address and thus it can't determine the sent the message to a unicast or broadcast address and thus the
client's state. [RFC5010] introduced the "Flags Suboption" which server may be unable to correctly determine the client's state.
relay agents add to relayed messages to indicate whether broadcast or [RFC5010] introduced the "Flags Suboption" that relay agents add to
unicast was used by the client. relayed messages to indicate whether broadcast or unicast was used by
the client.
In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the
4o6 DHCP Server. There is no relation between the outer IPv6 address 4o6 DHCP Server. There is no relation between the outer IPv6 address
and the inner DHCPv4 message. So the server is not able to know and the inner DHCPv4 message. As a result, the server is unable to
whether the DHCPv4 messages should have been sent using broadcast or determine whether the received DHCPv4 messages should have been sent
unicast in IPv4 by checking the IPv6 address. This is similar to the using broadcast or unicast in IPv4 by checking the IPv6 address.
case addressed by the [RFC5010]. This is similar to the case addressed by [RFC5010].
In order to allow the server to determine the client's state, the In order to allow the server to determine the client's state, the
"Unicast" flag is carried in the Boot-request-v6 message. Client "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 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 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 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 broadcast address in IPv4. The choice whether a given message should
be sent to a broadcast or unicast address MUST be made based on the be sent to a broadcast or unicast address is made based on the
[RFC2131] and its extensions. [RFC2131] and its extensions.
8. 4o6 DHCP Client Behavior Note: The "Unicast" flag reflects how the DHCPv4 packet would have
been sent; not how the DHCPv6 packet itself is sent.
The DHCPv4-over-DHCPv6 function MUST be disabled by default. The
client MUST obtain its IPv6 configuration before using DHCPv4 over
DHCPv6. The client that intends to use DHCPv4 over DHCPv6 MUST
request the DHCPv4-over-DHCPv6 Enable Option and SHOULD request the
4o6 Server Address Option in the Option Request Option (ORO) in every
Solicit, Request, Renew and Information-request messages. The 4o6
DHCP client MUST NOT request the DHCPv4-over-DHCPv6 Enable Option nor
the 4o6 Server Address Option in the Boot-request-v6 message.
The DHCPv6 server MAY include these options in the responses to the 8. DHCP 4o6 Client Behavior
client. The client determines how to enable the DHCPv4-over-DHCPv6
function based on the presence / absence of the two options:
o If the client doesn't receive the DHCPv4-over-DHCPv6 Enable The DHCPv4-over-DHCPv6 function MUST be disabled by default. The
option, it MUST NOT enable the DHCPv4-over-DHCPv6 function. In client MUST obtain the necessary IPv6 configuration before using
the case where the DHCPv4 over DHCPv6 service is running, the DHCPv4 over DHCPv6. A client intending to use DHCPv4 over DHCPv6
client MUST disable the function. MUST request the 4o6 Server Address option using Option Request
option (ORO) in every Solicit, Request, Renew and Information-request
message.
o If the client receives the DHCPv4-over-DHCPv6 Enable Option but no The DHCPv6 server MAY include the 4o6 Server Address option in its
4o6 Servers Address Option, it SHOULD enable the DHCPv4-over- response to the client. If the client receives this option, it MUST
DHCPv6 function and use IPv6 All_DHCP_Relay_Agents_and_Servers enable the DHCPv4-over-DHCPv6 function. The client MUST NOT enable
multicast address to communicate with servers and relays. the DHCPv4-over-DHCPv6 function if the DHCPv6 server does not include
the 4o6 Server Address option in its response. If the client does
not receive this option and DHCPv4 over DHCPv6 is already enabled,
the client MUST disable the DHCPv4-over-DHCPv6 function.
o If the client receives both options, it SHOULD enable the DHCPv4 If the DHCP 4o6 client receives the 4o6 Server Address option and
-over-DHCPv6 function and send requests to the unicast address(es) there is a DHCPv4 client active on the interface over which that
in the 4o6 Server Address Option. DHCPv6 option was received, it MUST stop the DHCPv4 client from
sending messages using [RFC2131].
o If the client only receives 4o6 Server Address Option, the client If the 4o6 client receives a 4o6 Server Address option that contains
MUST ignore the 4o6 Server Address Option and MUST NOT enable the no IP addresses, i.e. the option is empty, the DHCP 4o6 client MUST
DHCPv4-over-DHCPv6 function. 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 DHCP
4o6 client SHOULD send requests to each unique address carried by the
option.
The client supporting DHCPv4 over DHCPv6 SHOULD use Information The DHCP 4o6 client MUST employ an IPv6 address of an appropriate
Refresh Time Option [RFC4242] to refresh the status of DHCPv4-over- scope to source the DHCPv4-query message from. When the client sends
DHCPv6 service as well as other DHCPv6 configuration data. 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 the global IPv6 address, acquired in advance.
The client signaled by the server to use DHCPv4 over DHCPv6 SHOULD A client supporting DHCPv4 over DHCPv6 SHOULD use Information Refresh
cease to send DHCPv4 messages using DHCP protocol described in Time Option [RFC4242] to refresh the status of DHCPv4-over-DHCPv6
[RFC2131] and use the DHCPv4 over DHCPv6 to request IPv4 function as well as other DHCPv6 configuration data.
configuration from the 4o6 DHCP Server. The DHCPv4 message is stored
verbatim in the BOOTP Message option carried by the Boot-request-v6
message. The client MUST put exactly one BOOTP Message option into a
single Boot-request-v6 message.
Client MUST follow rules defined in Section 7 when setting Unicast The client generates a DHCPv4 message and stores it verbatim in the
flag. 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 4o6 Server
Address option in the DHCPv4-query message.
If the client has not received the 4o6 Server Addresses option from The client MUST follow rules defined in Section 7 when setting the
the DHCPv6 server, it transmits the Boot-request-v6 message as Unicast flag based on the DHCPv4 destination.
specified in Section 13 of [RFC3315]. If the client received this
option, it SHOULD send Boot-request-v6 message to all unicast
addresses listed in the option.
On receiving a Boot-reply-v6 message, the client MUST look for the On receiving a DHCPv4-response message, the client MUST look for the
BOOTP Message option within this message. If this option is not DHCPv4 Message option within this message. If this option is not
found, the Boot-reply-v6 message is discarded. If the BOOTP Message found, the DHCPv4-response message is discarded. If the DHCPv4
Option presents, the client extracts the DHCPv4 message it contains Message option is present, the client extracts the DHCPv4 message it
and processes it as described in section 4.4 of [RFC2131]. contains and processes it as described in section 4.4 of [RFC2131].
When dealing with IPv4 configuration, the 4o6 DHCP client SHOULD When dealing with IPv4 configuration, the DHCP 4o6 client MUST follow
follow the normal DHCPv4 retransmission requirements and strategy as the normal DHCPv4 retransmission requirements and strategy as
specified in section 4.1 of [RFC2131]. There are no explicit specified in section 4.1 of [RFC2131]. There are no explicit
transmission parameters associated with a Boot-request-v6 message. transmission parameters associated with a DHCPv4-query message, as
this is governed by the DHCPv4 [RFC2131] "state machine".
The 4o6 DHCP client MUST implement [RFC4361] to ensure that the The DHCP 4o6 client MUST implement [RFC4361] to ensure that the
device correctly identifies itself. device correctly identifies itself.
9. Relay Agent Behavior 9. Relay Agent Behavior
When a DHCPv6 relay agent receives a Boot-request-v6 message, it may When a DHCPv6 relay agent receives a DHCPv4-query message, it may not
not recognize this message. It can just forward this message as in recognize this message. The unknown message can be forwarded as
[I-D.ietf-dhc-dhcpv6-unknown-msg]. described in [I-D.ietf-dhc-dhcpv6-unknown-msg].
Additionally, the DHCPv6 relay agent MAY allow the configuration of a Additionally, the DHCPv6 relay agent MAY allow the configuration of a
dedicated DHCPv4 over DHCPv6 specific destination address(es), dedicated DHCPv4 over DHCPv6 specific destination address(es),
differing from the address(es) of the DHCPv6-only server(s). To differing from the address(es) of the DHCPv6-only server(s). To
implement this function, the relay checks the received DHCPv6 message implement this function, the relay checks the received DHCPv6 message
type and forwards according to the following logic: type and forwards according to the following logic:
1. If the message type is BOOTREQUESTV6, the packet is relayed to 1. If the message type is DHCPV4-QUERY, the packet is relayed to the
the configured 4o6 DHCP Server's address(es) in the form of configured DHCP 4o6 Server's address(es) in the form of normal
normal DHCPv6 packet (i.e. DHCPv6/UDP/IPv6). DHCPv6 packet (i.e. DHCPv6/UDP/IPv6).
2. For any other DHCPv6 message type, forward according to section 2. For any other DHCPv6 message type, forward according to section
20 of [RFC3315]. 20 of [RFC3315].
The above logic only allows for separate relay destinations The above logic only allows for separate relay destinations
configured on the relay agent closest to the client (single relay configured on the relay agent closest to the client (single relay
hop). Multiple relaying hops are not considered in the case of hop). Multiple relaying hops are not considered in the case of
separate relay destinations. separate relay destinations.
10. 4o6 DHCP Server Behavior 10. DHCP 4o6 Server Behavior
When the server receives a Boot-request-v6 message from a client, it When the server receives a DHCPv4-query message from a client, it
searches for the BOOTP Message Option. The server discards the searches for the DHCPv4 Message option. The server discards the
packet without this option. The server MAY notify an administrator packet without this option. The server MAY notify an administrator
about the receipt of a malformed packet. The mechanism for this about the receipt of a malformed packet. The mechanism for this
notification is out of scope for this document notification is out of scope for this document.
If the server finds a valid BOOTP Message option, it extracts the If the server finds a valid DHCPv4 Message option, it extracts the
original DHCPv4 message and the contents of the "flags" field carried original DHCPv4 message and the contents of the "flags" field carried
in the Boot-request-v6 message and uses them to generate the in the DHCPv4-query message and uses them to generate the appropriate
appropriate DHCPv4 response (server to client message). The response DHCPv4 response (server to client message). The response is
is generated as described in [RFC2131] with the exception that the generated as described in [RFC2131] with the exception that the
server SHOULD use the information carried in the "flags" field of the server SHOULD use the information carried in the "flags" field of the
Boot-request-v6 message to find out whether the client's message DHCPv4-query message to find out whether the client's message would
would have been sent to the broadcast or unicast address if DHCPv4 have been sent to the broadcast or unicast address if IPv4 has been
protocol was used. This is useful for the server to determine the used. This is useful for the server to determine the state of the
state of the client. The use of the "flags" field is described in client. The use of the "flags" field is described in detail in
detail in Section 7. Section 7. Since the client MUST use a client identifier to identify
itself (as per [RFC4361]), the server MUST implement [RFC6842] and
use the client identifier in all DHCPv4 message exchanges with the
client.
When appropriate DHCPv4 response is generated, the 4o6 Server places When an appropriate DHCPv4 response is generated, the 4o6 Server
it in the payload of a BOOTP Message Option, which it puts into the places it in the payload of a DHCPv4 Message option, which it puts
Boot-reply-v6 message. into the DHCPv4-response message.
If the Boot-request-v6 message was received directly by the server, If the DHCPv4-query message was received directly by the server, the
the Boot-reply-v6 message MUST be unicast from the interface on which DHCPv4-response message MUST be unicast from the interface on which
the original message was received. the original message was received.
If the Boot-request-v6 message was received in a Relay-forward If the DHCPv4-query message was received in a Relay-forward message,
message, the server creates a Relay-reply message with the Boot- the server creates a Relay-reply message with the DHCPv4-response
reply-v6 message in the payload of a Relay Message option, and message in the payload of a Relay Message option, and responds as
responds as described in section 20.3 of [RFC3315]. described in section 20.3 of [RFC3315].
11. Security Considerations 11. Security Considerations
In this specification, DHCPv4 messages are encapsulated in the newly In this specification, DHCPv4 messages are encapsulated in the newly
defined option and messages. This is similar to the handling of the defined option and messages. This is similar to the handling of the
current relay agent messages. In order to bypass firewalls or current relay agent messages. In order to bypass firewalls or
network authentication gateways, a malicious attacker may leverage network authentication gateways, a malicious attacker may leverage
this feature to convey other messages using DHCPv6, i.e. use DHCPv6 this feature to convey other messages using DHCPv6, i.e. use DHCPv6
as a form of encapsulation. However, the potential risk from this is as a form of encapsulation. However, the potential risk from this is
no more severe than that with the current DHCPv4 and DHCPv6 practice. no more severe than that with the current DHCPv4 and DHCPv6 practice.
There are chances that a rogue DHCPv6 server may reply with a 4o6 It is possible for a rogue DHCPv6 server to reply with a 4o6 Server
Server Address Option containing duplicated unicast IPv6 addresses, Address Option containing duplicated IPv6 addresses, which could
which can cause an amplification attack. To avoid this, the client cause an amplification attack. To avoid this, the client MUST check
MUST check if there are repeated IPv6 addresses in a 4o6 Server if there are duplicate IPv6 addresses in a 4o6 Server Address Option
Address Option when receiving one. The client MUST ignore those when receiving one. The client MUST ignore those duplicated IPv6
duplicated unicast IPv6 addresses. addresses.
12. IANA Considerations 12. IANA Considerations
IANA is requested to allocate three DHCPv6 option codes for use by IANA is requested to allocate two DHCPv6 option codes for use by
OPTION_BOOTP_MSG, OPTION_DHCP4_O_DHCP6_ENABLE and OPTION_DHCPV4_MSG and OPTION_DHCP4_O_DHCP6_SERVER from the "DHCP
OPTION_DHCP4_O_DHCP6_SERVERS, and two DHCPv6 message type codes for Option Codes" table, and two DHCPv6 message type codes for the
the BOOTREQUESTV6 and BOOTREPLYV6. DHCPV4-QUERY and DHCPV4-RESPONSE from the "DHCP Message Codes" table
of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Registry. Both tables can be found at http://www.iana.org/
assignments/dhcpv6-parameters/dhcpv6-parameters.xml.
13. Contributors List 13. Contributors List
Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Yuchi Chen Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Yuchi Chen
and Cong Liu, for their great contributions to the draft. and Cong Liu, for their great contributions to the draft.
14. References 14. References
14.1. Normative References 14.1. Normative References
skipping to change at page 13, line 5 skipping to change at page 13, line 27
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Time Option for Dynamic Host Configuration Protocol for Time Option for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 4242, November 2005. IPv6 (DHCPv6)", RFC 4242, November 2005.
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
Identifiers for Dynamic Host Configuration Protocol Identifiers for Dynamic Host Configuration Protocol
Version Four (DHCPv4)", RFC 4361, February 2006. Version Four (DHCPv4)", RFC 4361, February 2006.
[RFC6842] Swamy, N., Halwasia, G., and P. Jhingran, "Client
Identifier Option in DHCP Server Replies", RFC 6842,
January 2013.
14.2. Informative References 14.2. Informative References
[I-D.ietf-dhc-dhcpv6-unknown-msg] [I-D.ietf-dhc-dhcpv6-unknown-msg]
Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6
Messages", draft-ietf-dhc-dhcpv6-unknown-msg-03 (work in Messages", draft-ietf-dhc-dhcpv6-unknown-msg-04 (work in
progress), November 2013. progress), December 2013.
[RFC5010] Kinnear, K., Normoyle, M., and M. Stapp, "The Dynamic Host [RFC5010] Kinnear, K., Normoyle, M., and M. Stapp, "The Dynamic Host
Configuration Protocol Version 4 (DHCPv4) Relay Agent Configuration Protocol Version 4 (DHCPv4) Relay Agent
Flags Suboption", RFC 5010, September 2007. Flags Suboption", RFC 5010, September 2007.
Authors' Addresses Authors' Addresses
Qi Sun Qi Sun
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
 End of changes. 96 change blocks. 
289 lines changed or deleted 304 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/