draft-ietf-dhc-dhcpv4-over-dhcpv6-08.txt   draft-ietf-dhc-dhcpv4-over-dhcpv6-09.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: November 24, 2014 M. Siodelski Expires: December 13, 2014 M. Siodelski
ISC ISC
S. Krishnan S. Krishnan
Ericsson Ericsson
I. Farrer I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
May 23, 2014 June 11, 2014
DHCPv4 over DHCPv6 Transport DHCPv4 over DHCPv6 Transport
draft-ietf-dhc-dhcpv4-over-dhcpv6-08 draft-ietf-dhc-dhcpv4-over-dhcpv6-09
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 and two new DHCPv6 options are defined for this purpose. messages and two new DHCPv6 options are defined for this purpose.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 November 13, 2014. This Internet-Draft will expire on December 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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
described in the Simplified BSD License. described in the Simplified BSD License.
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. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
5. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 5 5. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4
5.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 5 6. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 5
5.2. Message Formats . . . . . . . . . . . . . . . . . . . . . 5 6.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 6
5.3. DHCPv4-query Message Flags . . . . . . . . . . . . . . . 6 6.2. Message Formats . . . . . . . . . . . . . . . . . . . . . 6
5.4. DHCPv4-response Message Flags . . . . . . . . . . . . . . 7 6.3. DHCPv4-query Message Flags . . . . . . . . . . . . . . . 7
6. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 7 6.4. DHCPv4-response Message Flags . . . . . . . . . . . . . . 7
6.1. DHCPv4 Message Option Format . . . . . . . . . . . . . . 7 7. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 7
6.2. 4o6 Server Address Option Format . . . . . . . . . . . . 8 7.1. DHCPv4 Message Option Format . . . . . . . . . . . . . . 7
7. Use of the DHCPv4-query Unicast Flag . . . . . . . . . . . . 9 7.2. 4o6 Server Address Option Format . . . . . . . . . . . . 8
8. DHCP 4o6 Client Behavior . . . . . . . . . . . . . . . . . . 9 8. Use of the DHCPv4-query Unicast Flag . . . . . . . . . . . . 9
9. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 11 9. DHCP 4o6 Client Behavior . . . . . . . . . . . . . . . . . . 10
10. DHCP 4o6 Server Behavior . . . . . . . . . . . . . . . . . . 12 10. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. DHCP 4o6 Server Behavior . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. Contributors List . . . . . . . . . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 14. Contributors List . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 13 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 14 15.1. Normative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 15.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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. In such networks, 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 provisioning IPv4 addresses for clients of this service, addition to provisioning IPv4 addresses for clients of this service,
other IPv4 configuration parameters may also be needed (e.g. other IPv4 configuration parameters may also be needed (e.g.
addresses of IPv4-only services). addresses of IPv4-only services).
skipping to change at page 3, line 47 skipping to change at page 4, line 5
DHCP 4o6 server (or server): A DHCP server that is capable of DHCP 4o6 server (or server): A DHCP server that is capable of
processing DHCPv4 packets processing DHCPv4 packets
encapsulated in the DHCPv4 Message encapsulated in the DHCPv4 Message
option (defined below). option (defined below).
DHCPv4 over DHCPv6: A protocol described in this DHCPv4 over DHCPv6: A protocol described in this
document, used to carry DHCPv4 document, used to carry DHCPv4
messages in the payload of DHCPv6 messages in the payload of DHCPv6
messages. messages.
4. Architecture Overview 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
the "client behavior" section; 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 may be enabled automatically in accordance with the needs
of some dual-stack transition mechanism such as
[I-D.ietf-softwire-lw4over6]. Such mechanisms are beyond the scope
of this document.
5. Architecture Overview
The architecture described here addresses a typical use case, where a The architecture described here addresses a typical use case, where a
DHCP client's uplink supports IPv6 only and the Service Provider's DHCP client's uplink supports IPv6 only and the Service Provider's
network supports IPv6 and limited IPv4 services. In this scenario, network supports IPv6 and limited IPv4 services. In this scenario,
the client can only use the IPv6 network to access IPv4 services, so the client can only use the IPv6 network to access IPv4 services, so
IPv4 services must be configured using IPv6 as the underlying network IPv4 services must be configured using IPv6 as the 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 to DHCPv4 only. As the DHCPv4 message is a special messages types to DHCPv4 only. As the DHCPv4 message is a special
type of BOOTP message, BOOTP messages can also be transported using type of BOOTP message, BOOTP messages [RFC0951] MAY also be
the same mechanism. transported using the same mechanism.
DHCP clients may be running on CPE devices, end hosts or any other DHCP clients may be running on CPE devices, end hosts or any other
device that supports the DHCP client function. This document uses device that supports the DHCP client function. This document uses
the CPE as an example for describing the mechanism. This does not the CPE as an example for describing the mechanism. This does not
preclude any end-host, or other device requiring IPv4 configuration, preclude any end-host, or other device requiring IPv4 configuration,
from implementing DHCPv4 over DHCPv6 in the future. 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 the newly defined DHCPv6 messages. The DHCPv6 relay encapsulation is
deployment architecture. used solely to deliver DHCPv4 packets to a DHCPv4-capable server, and
do not allocate any IPv6 addresses nor provide IPv6 configuration
information to the client. Figure 1, below, illustrates one possible
deployment architecture of this mechanism.
The DHCP 4o6 client implements a new DHCPv6 message called The DHCP 4o6 client implements a new DHCPv6 message called
DHCPv4-query, which contains a new option called the DHCPv4 Message DHCPv4-query, which contains a new option called the DHCPv4 Message
option encapsulating a DHCPv4 message sent by the client. The format option encapsulating a DHCPv4 message sent by the client. The format
of this option is described in Section 6.1. of this option is described in Section 7.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 DHCP 4o6 server. The server replies with a or directly to the DHCP 4o6 server. The server replies with a
DHCPv4-response message, which is a new DHCPv6 message carrying the DHCPv4-response message, which is a new DHCPv6 message carrying the
DHCPv4 response encapsulated in the DHCPv4 Message option. DHCPv4 response encapsulated in the DHCPv4 Message option.
_____________ _____________ _____________ _____________
/ \ / \ / \ / \
| | | | | | | |
+--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+ +--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+
| DHCP 4o6 | network | DHCPv6 | network | DHCP 4o6 | | 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 Before the client can use DHCPv4 over DHCPv6, it MUST obtain the
client. Before the client can use DHCPv4 over DHCPv6, it MUST obtain necessary IPv6 configuration. The client requests the 4o6 Server
the necessary IPv6 configuration. The client requests the 4o6 Server
Address option from the server by sending the option code in Option Address option from the server by sending the option code in Option
Request option as described in [RFC3315]. If the server responds Request option as described in [RFC3315]. If the server responds
with the 4o6 Server Address option, it is an indication to the client with the 4o6 Server Address option, it is an indication to the client
to attempt using DHCPv4 over DHCPv6 to obtain IPv4 configuration. 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 The client obtains the address(es) of the DHCP 4o6 server(s) from the
4o6 Server Address option and uses them to communicate with the DHCP 4o6 Server Address option and uses them to communicate with the DHCP
4o6 servers as described in Section 8. If the 4o6 Server Address 4o6 servers as described in Section 9. If the 4o6 Server Address
option contains no addresses (is empty), the client uses the well- option contains no addresses (is empty), the client uses the well-
known All_DHCP_Relay_Agents_and_Servers multicast address to known All_DHCP_Relay_Agents_and_Servers multicast address to
communicate with the DHCP 4o6 server(s). communicate with the DHCP 4o6 server(s).
Before applying for an IPv4 address via a DHCPv4-query message, the Before applying for an IPv4 address via a DHCPv4-query message, the
client must identify a suitable network interface for the address. client must identify a suitable network interface for the address.
Once the request is acknowledged by the server, the client can Once the request is acknowledged by the server, the client can
configure the address and other relevant parameters on this configure the address and other relevant parameters on this
interface. The mechanism for determining a suitable interface is out interface. The mechanism for determining a suitable interface is out
of the scope of the document. of the scope of the document.
5. New DHCPv6 Messages 6. New DHCPv6 Messages
Two new DHCPv6 messages carry DHCPv4 messages between the client and Two new DHCPv6 messages carry DHCPv4 messages between the client and
the server using the DHCPv6 protocol: DHCPv4-query and the server using the DHCPv6 protocol: DHCPv4-query and
DHCPv4-response. This section describes the structures of these DHCPv4-response. This section describes the structures of these
messages. messages.
5.1. Message Types 6.1. Message Types
DHCPV4-QUERY (TBD): The DHCP 4o6 client sends a DHCPv4-query DHCPV4-QUERY (TBD): The DHCP 4o6 client sends a DHCPv4-query
message to a DHCP 4o6 server. The DHCPv4 message to a DHCP 4o6 server. The DHCPv4
Message option carried by this message Message option carried by this message
contains a DHCPv4 message that the DHCP 4o6 contains a DHCPv4 message that the DHCP 4o6
client uses to request IPv4 configuration client uses to request IPv4 configuration
parameters from the server. parameters from the server.
DHCPv4-RESPONSE (TBD): A DHCP 4o6 server sends a DHCPv4-response DHCPv4-RESPONSE (TBD): A DHCP 4o6 server sends a DHCPv4-response
message to a DHCP 4o6 client. It contains a message to a DHCP 4o6 client. It contains a
DHCPv4 Message option carrying a DHCPv4 DHCPv4 Message option carrying a DHCPv4
message in response to a DHCPv4 message message in response to a DHCPv4 message
received by the server in the DHCPv4 Message received by the server in the DHCPv4 Message
option of the DHCPv4-query message. option of the DHCPv4-query message.
5.2. Message Formats 6.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 6, line 30 skipping to change at page 6, line 51
corresponding to the contained DHCPv4-query or corresponding to the contained DHCPv4-query or
DHCPv4-response, respectively. DHCPv4-response, respectively.
flags Specifies flags providing additional information flags Specifies flags providing additional information
required by the server to process the DHCPv4 message required by the server to process the DHCPv4 message
encapsulated in the DHCPv4-query message, or required encapsulated in the DHCPv4-query message, or required
by the client to process a DHCPv4 message by the client to process a DHCPv4 message
encapsulated in the DHCPv4-response message. encapsulated in the DHCPv4-response message.
options Options carried by the message. The DHCPv4 Message options Options carried by the message. The DHCPv4 Message
Option (described in Section 6.1) MUST be carried by Option (described in Section 7.1) MUST be carried by
the message. Only DHCPv6 options for IPv4 the message. Only DHCPv6 options for IPv4
configuration may be included in this field. It MUST configuration may be included in this field. It MUST
NOT contain DHCPv6 options related solely to IPv6, or NOT contain DHCPv6 options related solely to IPv6, or
IPv6-only service configuration. IPv6-only service configuration.
5.3. DHCPv4-query Message Flags 6.3. DHCPv4-query Message Flags
The "flags" field of the DHCPv4-query is used to carry additional The "flags" field of the DHCPv4-query is used to carry additional
information that 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 10 skipping to change at page 7, line 31
Figure 3: DHCPv4-query 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 within the DHCPv4-query 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
the broadcast address if it was sent using IPv4. The the broadcast address if it was sent using IPv4. The
usage of the flag is described in detail in usage of the flag is described in detail in
Section 7. Section 8.
MBZ Bits MUST be set to zero when sending and MUST be MBZ Bits MUST be set to zero when sending and MUST be
ignored when receiving. ignored when receiving.
5.4. DHCPv4-response Message Flags 6.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 DHCPv4-response message. They are all reserved for the future of the DHCPv4-response message. They are all reserved for the future
use. The DHCP 4o6 server MUST set all bits of this field to 0 and 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. the DHCP 4o6 client MUST ignore the content in this field.
6. New DHCPv6 Options 7. New DHCPv6 Options
6.1. DHCPv4 Message Option Format 7.1. DHCPv4 Message Option Format
The DHCPv4 Message option carries a DHCPv4 message that is sent by The DHCPv4 Message option carries a DHCPv4 message that is sent by
the client or the server. Such messages exclude any IP or UDP the client or the server. Such messages exclude any IP or UDP
headers. headers.
The format of the DHCPv4 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_DHCPV4_MSG | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. DHCPv4-message . . DHCPv4-message .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DHCPv4 Message option Format Figure 4: DHCPv4 Message option Format
option-code OPTION_DHCPV4_MSG (TBD). option-code OPTION_DHCPV4_MSG (TBD).
option-len Length of the DHCPv4 message. option-len Length of the DHCPv4 message.
DHCPv4-message The DHCPv4 message sent by the client or the server. DHCPv4-message The DHCPv4 message sent by the client or the server.
In a DHCPv4-query message it contains a DHCPv4 In a DHCPv4-query message it contains a DHCPv4
message sent by a client. In a DHCPv4-response message sent by a client. In a DHCPv4-response
message it contains a DHCPv4 message sent by a server message it contains a DHCPv4 message sent by a server
in response to a client. in response to a client.
6.2. 4o6 Server Address Option Format 7.2. 4o6 Server Address Option Format
The 4o6 Server Address option is sent by a server to a client The 4o6 Server Address option is sent by a server to a client
requesting IPv6 configuration using DHCPv6 [RFC3315]. It carries a requesting IPv6 configuration using DHCPv6 [RFC3315]. It carries a
list of DHCP 4o6 server's IPv6 addresses that the client should list of DHCP 4o6 servers' IPv6 addresses that the client should
contact to obtain IPv4 configuration. This list may include contact to obtain IPv4 configuration. This list may include
multicast and unicast addresses. The client sends its requests to multicast and unicast addresses. The client sends its requests to
all unique addresses carried in this option. all unique addresses carried in this option.
This option may also carry no IPv6 addresses, which instructs the This option may also carry no IPv6 addresses, which instructs the
client to use the All_DHCP_Relay_Agents_and_Servers multicast address client to use the All_DHCP_Relay_Agents_and_Servers multicast address
as the destination address. as the destination address.
The presence of this option in the server's response indicates to the The presence of this option in the server's response indicates to the
client that it should use DHCPv4 over DHCPv6 to obtain IPv4 client that it should use DHCPv4 over DHCPv6 to obtain IPv4
configuration. If the option is absent, the client MUST NOT enable configuration. If the option is absent, the client MUST NOT enable
DHCPv4-over-DHCPv6 function. 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-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. IPv6 Address(es) . . IPv6 Address(es) .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: 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. Minimal length of this i.e. multiple of 16 octets. Minimal length of this
option is 0. option is 0.
IPv6 Address Zero or more IPv6 addresses of the DHCP 4o6 IPv6 Address Zero or more IPv6 addresses of the DHCP 4o6
Server(s). Server(s).
7. Use of the DHCPv4-query Unicast Flag 8. Use of the DHCPv4-query Unicast Flag
A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST
message to either a broadcast or unicast address depending on its message to either a broadcast or unicast address depending on its
state. For example, a client in the RENEWING state uses a unicast 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 address to contact the DHCPv4 server to renew its lease. A client in
the REBINDING state uses a broadcast address. the REBINDING state uses a broadcast address.
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
DHCP 4o6 server. There is no relation between the outer IPv6 address 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 and the inner DHCPv4 message. As a result, the server is unable to
skipping to change at page 9, line 31 skipping to change at page 10, line 5
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 is 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.
Note: The "Unicast" flag reflects how the DHCPv4 packet would have Note: The "Unicast" flag reflects how the DHCPv4 packet would have
been sent; not how the DHCPv6 packet itself is sent. been sent; not how the DHCPv6 packet itself is sent.
8. DHCP 4o6 Client Behavior 9. DHCP 4o6 Client Behavior
The DHCPv4-over-DHCPv6 function MUST be disabled by default. The The client MUST obtain necessary IPv6 configuration from a DHCPv6
client MUST obtain the necessary IPv6 configuration (stateless or server before using DHCPv4 over DHCPv6. The client requests the 4o6
stateful) before using DHCPv4 over DHCPv6. The client intending to Server Address option using Option Request option (ORO) in every
use DHCPv4 over DHCPv6 MUST request the 4o6 Server Address option Solicit, Request, Renew, Rebind and Information-request message. If
using Option Request option (ORO) in every Solicit, Request, Renew, the DHCPv6 server includes the 4o6 Server Address option in its
Rebind and Information-request message. 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 server MAY include the 4o6 Server Address option in its response The client MUST NOT use DHCPv4 over DHCPv6 to request IPv4
to the client. If the client receives this option, it enables the configuration if the DHCPv6 server does not include the 4o6 Server
DHCPv4-over-DHCPv6 function. The client MUST NOT enable the DHCPv4 Address option. If the IPv6 configuration that contained the 4o6
-over-DHCPv6 function if the server does not include the 4o6 Server Server Address option subsequently expires, or if the renewed IPv6
Address option in its response. If the DHCPv6 configuration that configuration does not contain the 4o6 Server Address option, the
contained the 4o6 Server Address option subsequently expires, the client MUST stop using DHCPv4 over DHCPv6 to request or renew IPv4
client MUST disable the DHCPv4-over-DHCPv6 function. If, when the configuration. However, the client continues to request 4o6 Server
DHCPv6 configuration that contained the 4o6 Server Address option is Address option in the messages sent to the DHCPv6 server as long as
renewed, the renewed configuration does not contain a 4o6 Server it desires to use DHCPv4 over DHCPv6.
Address option, the client MUST disable the DHCPv4-over-DHCPv6
function.
It is possible in a multi-homed configuration for there to be more It is possible in a multi-homed configuration for there to be more
than one DHCPv6 configuration active at the same time that contains a than one DHCPv6 configuration active at the same time that contains a
4o6 Server Address option. In this case, the configurations are 4o6 Server Address option. In this case, the configurations are
treated as being independent, so that when any such configuration is treated as being independent, so that when any such configuration is
active, a DHCPv4-over-DHCPv6 function may be enabled for that active, a DHCPv4-over-DHCPv6 function may be enabled for that
configuration. configuration.
An implementation may also treat such configurations as being An implementation may also treat such configurations as being
exclusive, such that only one is kept active at a time. In this exclusive, such that only one is kept active at a time. In this
case, the client keeps the same configuration active continuously as case, the client keeps the same configuration active continuously as
long as it is valid. If that configuration becomes invalid but one long as it is valid. If that configuration becomes invalid but one
or more other configurations remain valid, the client activates one or more other configurations remain valid, the client activates one
of the remaining valid configurations. of the remaining valid configurations.
Which strategy to follow is dependent on the implementation: keeping Which strategy to follow is dependent on the implementation: keeping
multiple configurations active at the same time may provide useful multiple configurations active at the same time may provide useful
redundancy in some applications, but may be needlessly complex in redundancy in some applications, but may be needlessly complex in
other cases. other cases.
If the client receives the 4o6 Server Address option and there is a If the client receives the 4o6 Server Address option and DHCPv4
DHCPv4 client active on the interface over which that DHCPv6 option [RFC2131] is used on the interface over which the DHCPv6 option was
was received, it MUST stop the DHCPv4 client from sending messages received, the client MUST stop using the IPv4 configuration received
using [RFC2131]. using DHCPv4 on this interface. The client MAY send a DHCPRELEASE to
the DHCPv4 server to relinquish an existing lease as described in
[RFC2131] in section 4.4.6. The client MUST NOT use DHCPv4 on this
interface as long as it receives 4o6 Server Address option in the
messages received from the DHCPv6 server.
If the client receives a 4o6 Server Address option that contains no If the client receives a 4o6 Server Address option that contains no
IP addresses, i.e. the option is empty, the client MUST send its IP addresses, i.e. the option is empty, the client MUST send its
requests to the All_DHCP_Relay_Agents_and_Servers multicast address. 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 If there is a list of IP addresses in the option, the client SHOULD
send requests to each unique address carried by the option. send requests to each unique address carried by the option.
If the client obtained stateless IPv6 configuration by sending If the client obtained stateless IPv6 configuration by sending
Information-request message to the server, the client MUST follow the Information-request message to the server, the client MUST follow the
rules in [RFC4242] to periodically refresh the DHCPv4-over-DHCPv6 rules in [RFC4242] to periodically refresh the DHCPv4-over-DHCPv6
skipping to change at page 11, line 7 skipping to change at page 11, line 33
local address as the source address as described in [RFC3315]. When local address as the source address as described in [RFC3315]. When
the client sends a DHCPv4-query message using unicast, the source the client sends a DHCPv4-query message using unicast, the source
address MUST be an address of appropriate scope, acquired in advance. address MUST be an address of appropriate scope, acquired in advance.
The client generates a DHCPv4 message and stores it verbatim in the The client generates a DHCPv4 message and stores it verbatim in the
DHCPv4 Message option carried by the DHCPv4-query message. The DHCPv4 Message option carried by the DHCPv4-query message. The
client MUST put exactly one DHCPv4 Message option into a single client MUST put exactly one DHCPv4 Message option into a single
DHCPv4-query message. The client MUST NOT request the 4o6 Server DHCPv4-query message. The client MUST NOT request the 4o6 Server
Address option in the DHCPv4-query message. Address option in the DHCPv4-query message.
The client MUST follow rules defined in Section 7 when setting the The client MUST follow rules defined in Section 8 when setting the
Unicast flag based on the DHCPv4 destination. Unicast flag based on the DHCPv4 destination.
On receiving a DHCPv4-response message, the client MUST look for the On receiving a DHCPv4-response message, the client MUST look for the
DHCPv4 Message option within this message. If this option is not DHCPv4 Message option within this message. If this option is not
found, the DHCPv4-response message is discarded. If the DHCPv4 found, the DHCPv4-response message is discarded. If the DHCPv4
Message option is present, the client extracts the DHCPv4 message it Message option is present, the client extracts the DHCPv4 message it
contains 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 client MUST follow the When dealing with IPv4 configuration, the client MUST follow the
normal DHCPv4 retransmission requirements and strategy as specified normal DHCPv4 retransmission requirements and strategy as specified
in section 4.1 of [RFC2131]. There are no explicit transmission in section 4.1 of [RFC2131]. There are no explicit transmission
parameters associated with a DHCPv4-query message, as this is parameters associated with a DHCPv4-query message, as this is
governed by the DHCPv4 [RFC2131] "state machine". governed by the DHCPv4 [RFC2131] "state machine".
The client MUST implement [RFC4361] to ensure that the device The client MUST implement [RFC4361] to ensure that the device
correctly identifies itself. correctly identifies itself. It MUST send a 'client identifier'
option when using DHCPv4 over DHCPv6.
9. Relay Agent Behavior 10. Relay Agent Behavior
When a DHCPv6 relay agent receives a DHCPv4-query message, it may not When a DHCPv6 relay agent receives a DHCPv4-query message, it may not
recognize this message. The unknown message can be forwarded as recognize this message. The unknown message MUST be forwarded as
described in [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 If it recognises the message, the DHCPv6 relay agent MAY allow the
dedicated DHCPv4 over DHCPv6 specific destination address(es), configuration of a dedicated DHCPv4 over DHCPv6 specific destination
differing from the address(es) of the DHCPv6-only server(s). To address(es), differing from the address(es) of the DHCPv6-only
implement this function, the relay checks the received DHCPv6 message server(s). To implement this function, the relay checks the received
type and forwards according to the following logic: DHCPv6 message type and forwards according to the following logic:
1. If the message type is DHCPV4-QUERY, the packet is relayed to the 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 normal configured DHCP 4o6 Server's address(es) in the form of 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. DHCP 4o6 Server Behavior 11. DHCP 4o6 Server Behavior
When the server receives a DHCPv4-query message from a client, it When the server receives a DHCPv4-query message from a client, it
searches for the DHCPv4 Message option. The server discards a packet searches for the DHCPv4 Message option. The server discards a packet
without this option. In addition, the server MAY notify an without this option. In addition, the server MAY notify an
administrator about the receipt of this malformed packet. The administrator about the receipt of this malformed packet. The
mechanism for this notification is out of scope for this document. mechanism for this notification is out of scope for this document.
If the server finds a valid DHCPv4 Message option, it extracts the If the server finds a valid DHCPv4 Message option, it extracts the
original DHCPv4 message. Since the DHCPv4 message is encapsulated in original DHCPv4 message. Since the DHCPv4 message is encapsulated in
the DHCPv6 message, it lacks the information which is typically used the DHCPv6 message, it lacks the information which is typically used
by the DHCPv4 server, implementing [RFC2131], to make address by the DHCPv4 server, implementing [RFC2131], to make address
allocation decisions, e.g. giaddr for relayed messages and IPv4 allocation decisions, e.g. giaddr for relayed messages and IPv4
address of the interface which the server using to communicate with address of the interface which the server is using to communicate
directly connected client. Therefore, the DHCP 4o6 server allocates with directly connected client. Therefore, the DHCP 4o6 server
addresses according to the local address assignment policies allocates addresses according to the local address assignment
determined by the server administrator. For example, if the policies determined by the server administrator. For example, if the
DHCPv4-query message has been sent via a relay, the server MAY use 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 link-address field of the Relay-forward message as a lookup for
the IPv4 subnet to assign DHCPv4 address from. If the DHCPv4-query the IPv4 subnet to assign DHCPv4 address from. If the DHCPv4-query
message has been sent from a directly connected client, the server message has been sent from a directly connected client, the server
MAY use IPv6 source address of the message to determine the MAY use IPv6 source address of the message to determine the
appropriate IPv4 subnet to use for DHCPv4 address assignment. appropriate IPv4 subnet to use for DHCPv4 address assignment.
Alternatively, the server may act as a DHCPv4 relay agent and forward 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 the DHCPv4 packet to a "normal" DHCPv4 server. The details of such a
solution have not been considered by the working group; describing solution have not been considered by the working group; describing
that solution is out of scope of this document and is left as future that solution is out of scope of this document and is left as future
work should the need for it arise. work should the need for it arise.
The server SHOULD use "flags" field of the DHCPv4-query message to The server SHOULD use the "flags" field of the DHCPv4-query message
create a response (server to client DHCPv4 message). The use of this to create a response (server to client DHCPv4 message). The use of
field is described in detail in Section 7. this field is described in detail in Section 8.
When an appropriate DHCPv4 response is created, the server places it When an appropriate DHCPv4 response is created, the server places it
in the payload of a DHCPv4 Message option, which it puts into the in the payload of a DHCPv4 Message option, which it puts into the
DHCPv4-response message. DHCPv4-response message.
If the DHCPv4-query message was received directly by the server, the If the DHCPv4-query message was received directly by the server, the
DHCPv4-response 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 DHCPv4-query message was received in a Relay-forward message, If the DHCPv4-query message was received in a Relay-forward message,
the server creates a Relay-reply message with the DHCPv4-response the server creates a Relay-reply message with the DHCPv4-response
message in the payload of a Relay Message option, and responds as message in the payload of a Relay Message option, and responds as
described in section 20.3 of [RFC3315]. described in section 20.3 of [RFC3315].
11. Security Considerations 12. 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.
It is possible for a rogue server to reply with a 4o6 Server Address It is possible for a rogue server to reply with a 4o6 Server Address
Option containing duplicated IPv6 addresses, which could cause an Option containing duplicated IPv6 addresses, which could cause an
amplification attack. To avoid this, the client MUST check if there amplification attack. To avoid this, the client MUST check if there
are duplicate IPv6 addresses in a 4o6 Server Address Option when are duplicate IPv6 addresses in a 4o6 Server Address Option when
receiving one. The client MUST ignore any but the first instance of receiving one. The client MUST ignore any but the first instance of
each address. each address.
12. IANA Considerations 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-
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 is requested to allocate two DHCPv6 option codes for use by IANA is requested to allocate two DHCPv6 option codes for use by
OPTION_DHCPV4_MSG and OPTION_DHCP4_O_DHCP6_SERVER from the "Option OPTION_DHCPV4_MSG and OPTION_DHCP4_O_DHCP6_SERVER from the "Option
Codes" table, and two DHCPv6 message type codes for the DHCPV4-QUERY Codes" table, and two DHCPv6 message type codes for the DHCPV4-QUERY
and DHCPV4-RESPONSE from the "Message Types" table of the Dynamic and DHCPV4-RESPONSE from the "Message Types" table of the Dynamic
Host Configuration Protocol for IPv6 (DHCPv6) Registry. Both tables Host Configuration Protocol for IPv6 (DHCPv6) Registry. Both tables
can be found at http://www.iana.org/assignments/dhcpv6-parameters/. can be found at http://www.iana.org/assignments/dhcpv6-parameters/.
13. Contributors List 14. Contributors List
Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Yuchi Chen Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Cong Liu and
and Cong Liu, for their great contributions to the draft. Yuchi Chen, for their great contributions to the specification.
14. References 15. References
14.1. Normative References 15.1. Normative References
[I-D.ietf-dhc-dhcpv6-unknown-msg]
Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6
Messages", draft-ietf-dhc-dhcpv6-unknown-msg-08 (work in
progress), March 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
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.
14.2. Informative References 15.2. Informative References
[I-D.ietf-dhc-dhcpv6-unknown-msg] [I-D.ietf-softwire-lw4over6]
Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
Messages", draft-ietf-dhc-dhcpv6-unknown-msg-08 (work in I. Farrer, "Lightweight 4over6: An Extension to the DS-
progress), March 2014. Lite Architecture", draft-ietf-softwire-lw4over6-10 (work
in progress), June 2014.
[RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985.
Authors' Addresses Authors' Addresses
Qi Sun Qi Sun
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
P.R.China P.R.China
Phone: +86-10-6278-5822 Phone: +86-10-6278-5822
Email: sunqi@csnet1.cs.tsinghua.edu.cn Email: sunqi@csnet1.cs.tsinghua.edu.cn
 End of changes. 47 change blocks. 
100 lines changed or deleted 146 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/