draft-ietf-dhc-dhcpv4-over-ipv6-07.txt   draft-ietf-dhc-dhcpv4-over-ipv6-08.txt 
Network Working Group Y. Cui Network Working Group Y. Cui
Internet-Draft P. Wu Internet-Draft P. Wu
Intended status: Informational J. Wu Intended status: Informational J. Wu
Expires: March 25, 2014 Tsinghua University Expires: April 24, 2014 Tsinghua University
T. Lemon T. Lemon
Nominum, Inc. Nominum, Inc.
September 21, 2013 Q. Sun
Tsinghua University
October 21, 2013
DHCPv4 over IPv6 Transport DHCPv4 over IPv6 Transport
draft-ietf-dhc-dhcpv4-over-ipv6-07 draft-ietf-dhc-dhcpv4-over-ipv6-08
Abstract Abstract
In IPv6 networks, there remains a need to provide IPv4 service for In IPv6 networks, there remains a need to provide IPv4 service for
some residual devices. This document describes a mechanism for some residual devices. This document describes a mechanism for
allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6 allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6
transport. It is done by putting a special relay agent function transport. It is done by putting a special relay agent function
(Client Relay Agent) on the client side, as well as extending the (Client Relay Agent) on the client side, as well as extending the
behavior of the server; in the case where DHCP server only supports behavior of the server; in the case where DHCP server only supports
IPv4 transport, a relay agent is extended to support IPv6 transport IPv4 transport, a relay agent is extended to support IPv6 transport
(IPv6-Transport Relay Agent) and relay DHCP traffic for the server, (IPv6-Transport Relay Agent) and relay DHCP traffic for the server,
with a new Relay Agent Information sub-option added to carry the IPv6 with a new Relay Agent Information sub-option added to carry the IPv6
address of the Client Relay Agent. address of the Client Relay Agent. DHCPv4 over IPv6 has been
developed in the IETF, and some implementations and deployments have
been carried out. But this mechanism is not recommended for future
implementation or deployment.
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 March 25, 2014. This Internet-Draft will expire on April 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 18 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 4
4. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . . 5 4. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . . 6
5. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . 6 5. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . 6
6. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 7 6. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 7
7. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . 8 7. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . 8
8. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 8
9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Motivation for selecting this particular solution . . 10 Appendix A. Motivation for selecting this particular solution . . 11
A.1. Configuring IPv4 with DHCPv6 . . . . . . . . . . . . . . 10 A.1. Configuring IPv4 with DHCPv6 . . . . . . . . . . . . . . 11
A.2. Tunnel DHCPv4 over IPv6 . . . . . . . . . . . . . . . . . 11 A.2. Tunnel DHCPv4 over IPv6 . . . . . . . . . . . . . . . . . 11
A.3. DHCPv4 relayed over IPv6 . . . . . . . . . . . . . . . . 11 A.3. DHCPv4 relayed over IPv6 . . . . . . . . . . . . . . . . 12
Appendix B. Discussion on One Host Retrieving Multiple Appendix B. Discussion on One Host Retrieving Multiple
Addresses through One CRA . . . . . . . . . . . . . . 12 Addresses through One CRA . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
DHCPv4 over IPv6 mechanism has been developed in the IETF. There
have been implementations from ISC, Juniper, Huawei, Tsinghua
University, etc. It is in active deployments in some networks,
including in the China Next Generation Internet (CNGI) and China
Education and Research Network 2 (CERNET2), Deutsche Telekom, and so
on. Documenting this mechanism is for the benefit of vendors and
operators of the existing implementations and deployments. According
to [I-D.ietf-dhc-v4configuration], future usage should reference
[I-D.ietf-dhc-dhcpv4-over-dhcpv6].
DHCPv4 [RFC2131] was not designed with IPv6 in mind: DHCPv4 cannot DHCPv4 [RFC2131] was not designed with IPv6 in mind: DHCPv4 cannot
operate on an IPv6 network. However, as dual-stack networks become a operate on an IPv6 network. However, as dual-stack networks become a
reality, the need arises to allocate IPv4 addresses in an IPv6 reality, the need arises to allocate IPv4 addresses in an IPv6
environment. To meet this demand, this document extends the DHCPv4 environment. To meet this demand, this document extends the DHCPv4
protocol to allow the use of an IPv6 network for transport. protocol to allow the use of an IPv6 network for transport.
A typical scenario that probably requires this feature is IPv4-over- A typical scenario that probably requires this feature is IPv4-over-
IPv6 hub and spoke tunnel [RFC4925]. In this scenario, IPv4-over- IPv6 hub and spoke tunnel [RFC4925]. In this scenario, IPv4-over-
IPv6 tunnel is used to provide IPv4 connectivity to end users (hosts IPv6 tunnel is used to provide IPv4 connectivity to end users (hosts
or end networks) across an IPv6 network. If the IPv4 addresses of or end networks) across an IPv6 network. If the IPv4 addresses of
skipping to change at page 4, line 44 skipping to change at page 5, line 7
+------+ |DHCPv4 | +------+ |DHCPv4 |
| IPv6 Network |Server/| | IPv6 Network |Server/|
+------+ |Relay | +------+ |Relay |
|DHCPv4| +-------+ |DHCPv4| +-------+
|Client| | |Client| |
+------+ | +------+ |
+-------------------------+ +-------------------------+
Figure 1 Scenario of DHCPv4 over IPv6 Transport Figure 1 Scenario of DHCPv4 over IPv6 Transport
The IPv6-Transport DHCPv4 server can receive DHCP messages delivered The IPv6-Transport DHCPv4 server is able to receive DHCP messages
in IPv6 UDP from the CRA, and send out DHCP messages to the CRA using delivered in IPv6 UDP from the CRA, and send out DHCP messages to the
IPv6 UDP (figure 2(a)). The TSV sends DHCP messages to the IPv6 CRA using IPv6 UDP (figure 2(a)). The TSV sends DHCP messages to the
address from which it receives relevant DHCP messages earlier. IPv6 address from which it receives relevant DHCP messages earlier.
When CRAs communicate with an IPv6-Transport Relay Agent rather than When CRAs communicate with an IPv6-Transport Relay Agent rather than
with a server directly, the situation becomes a little more with a server directly, the situation becomes a little more
complicated. Besides the IPv6 communication with a CRA, a TRA also complicated. Besides the IPv6 communication with a CRA, a TRA also
communicates with a regular DHCPv4 server through IPv4. Therefore, communicates with a regular DHCPv4 server through IPv4. Therefore,
when the TRA relays DHCP messages between a CRA and the DHCPv4 when the TRA relays DHCP messages between a CRA and the DHCPv4
server, it receives DHCP message from the CRA in IPv6 and sends it to server, it receives DHCP message from the CRA in IPv6 and sends it to
the server in IPv4, as well as receives DHCP message from the server the server in IPv4, as well as receives DHCP message from the server
in IPv4 and sends it to the CRA in IPv6. in IPv4 and sends it to the CRA in IPv6.
skipping to change at page 7, line 17 skipping to change at page 7, line 24
[I-D.ietf-dhc-dhcpv4-relay-encapsulation]. [I-D.ietf-dhc-dhcpv4-relay-encapsulation].
An HCRA only serves the client inside the same host, while the LCRA An HCRA only serves the client inside the same host, while the LCRA
serves any client on the link. When the IPv6 address of TSV/TRA is serves any client on the link. When the IPv6 address of TSV/TRA is
provisioned to the host running the DHCP client, it uses HCRA; else provisioned to the host running the DHCP client, it uses HCRA; else
the client depends on LCRA. A HCRA serves only one link; the the client depends on LCRA. A HCRA serves only one link; the
multiple-link case is handled by multiple HCRA instances. A LCRA multiple-link case is handled by multiple HCRA instances. A LCRA
does not necessarily need an IPv4 address, though it may be does not necessarily need an IPv4 address, though it may be
configured with one. configured with one.
In HCRA case, the DHCPv6 client (or other IPv6 configuration In the HCRA case, the DHCPv6 client (or other IPv6 configuration
processes), DHCPv4 client and CRA run on the same physical interface. processes), DHCPv4 client and CRA run on the same physical interface.
In some cases, the host running the DHCPv4 client and CRA defers the In some cases, the host running the DHCPv4 client and CRA defers the
operation of the DHCPv4 client until an IPv6 address of the interface operation of the DHCPv4 client until an IPv6 address of the interface
has been acquired, as well as the TSV/TRA address information. If has been acquired, as well as the TSV/TRA address information. If
this is not done, the DHCPv4 client may send several messages that this is not done, the DHCPv4 client may send several messages that
the CRA cannot relay, and this could result in long delays before the the CRA cannot relay, and this could result in long delays before the
DHCPv4 client actually gets an IPv4 address. DHCPv4 client actually gets an IPv4 address.
6. IPv6-Transport Server Behavior 6. IPv6-Transport Server Behavior
To support IPv6 transport, the behavior of DHCPv4 server is extended. To support IPv6 transport, the behavior of DHCPv4 server is extended.
The IPv6-Transport Server can listen on IPv6 port 67 for DHCPv4 The IPv6-Transport Server can listen on IPv6 port 67 for DHCPv4
messages, and send DHCPv4 messages through IPv6. messages, and send DHCPv4 messages through IPv6.
A TSV listens for DHCP messages on IPv6 UDP port 67 and IPv4 UDP port A TSV listens for DHCP messages on IPv6 UDP port 67 and IPv4 UDP port
67. When it receives a DHCP message on IPv6, it retains the IPv6 67. When it receives a DHCP message on IPv6, it retains the IPv6
source address of that message until it has sent a response. When it source address of that message until it has sent a response. When it
sends a response, it sends the response to this IPv6 address, with sends a response, it sends the response to this IPv6 address, with
destination port 67. destination port 67.
The TSV sends a server identifier option [RFC2132] containing an IPv4 The TSV is bound to send a server identifier option [RFC2132]
address which will be reachable from the client once the residual containing an IPv4 address which will be reachable from the client
IPv4 service is set up. This follows the server id option once the residual IPv4 service is set up. This follows the server id
requirement in [RFC2131]. option requirement in [RFC2131].
The rest of TSV DHCP process is the same with a normal DHCPv4 server.
The rest of TSV DHCP process is the same with normal DHCPv4 server.
A TSV also listens on IPv4 UDP port 67 like a normal DHCPv4 server, A TSV also listens on IPv4 UDP port 67 like a normal DHCPv4 server,
and process IPv4 DHCPv4 messages normally. This requirement exists and process IPv4 DHCPv4 messages normally. This requirement exists
because when a DHCPv4 client renews, it sends its renewal messages because when a DHCPv4 client renews, it sends its renewal messages
directly to the server, rather than broadcasting them. directly to the server, rather than broadcasting them.
Because the CRA may use relay agent encapsulation Because a CRA may use relay agent encapsulation
[I-D.ietf-dhc-dhcpv4-relay-encapsulation], the TSV supports it. A [I-D.ietf-dhc-dhcpv4-relay-encapsulation], the TSV ought to support
TSV that does not support it will not interoperate with a CRA that it. A TSV that does not support it will not interoperate with a CRA
sends relay agent options. that sends relay agent options.
7. IPv6-Transport Relay Agent Behavior 7. IPv6-Transport Relay Agent Behavior
An IPv6-Transport Relay Agent sits between IPv6 network and IPv4 An IPv6-Transport Relay Agent sits between an IPv6 network and an
network, and relays DHCPv4 message between CRAs and IPv4-only DHCPv4 IPv4 network, and relays DHCPv4 messages between CRAs and an IPv4-
server. The communication between CRAs and the TRA uses IPv6, while only DHCPv4 server. The communication between CRAs and the TRA uses
the communication between the TRA and the server uses IPv4. A TRA IPv6, while the communication between the TRA and the server uses
listens on IPv6 UDP port 67 for DHCP messages with BOOTP op field set IPv4. A TRA listens on IPv6 UDP port 67 for DHCP messages with BOOTP
to 1 or 3, as well as IPv4 UDP port 67 for DHCP messages with BOOTP op field set to 1 or 3, as well as IPv4 UDP port 67 for DHCP messages
op field set to 2 or 4. with BOOTP op field set to 2 or 4.
When relaying a DHCP message from CRA to server, the TRA adds a When relaying a DHCP message from CRA to server, the TRA adds a
CRA6ADDR suboption. The TRA sets the contents of this suboption to CRA6ADDR suboption. The TRA sets the contents of this suboption to
the IPv6 source address of the message. The TRA also stores one its the IPv6 source address of the message. The TRA also stores one its
own IPv4 addresses in the giaddr field of the DHCP message. The TRA own IPv4 addresses in the giaddr field of the DHCP message. The TRA
may include a Link Selection sub-option [RFC3527] to indicate to the may include a Link Selection sub-option [RFC3527] to indicate to the
DHCP server which link to use when choosing an IP address. If the DHCP server which link to use when choosing an IP address. If the
received message is a RELAYFORWARD message, the TRA encapsulates the received message is a RELAYFORWARD message, the TRA encapsulates the
message in a new RELAYFORWARD message and stores the CRA6ADDR in the message in a new RELAYFORWARD message and stores the CRA6ADDR in the
new relay segment. If it is some other message, the TRA appends a new relay segment. If it is some other message, the TRA appends a
Relay Agent Information Option as described in [RFC3046], but may Relay Agent Information Option as described in [RFC3046], but may
encapsulate it in the same way as RELAYFORWARD message instead, which encapsulate it in the same way as RELAYFORWARD message instead, which
depends on the implementation. depends on the implementation.
When receiving a DHCP message from the DHCP server, if the message When receiving a DHCP message from the DHCP server, if the message
contains no CRA6ADDR suboption, the TRA discards the message. contains no CRA6ADDR suboption, the TRA discards the message.
Otherwise, it processes it as required by [RFC3046] and Otherwise, it processes it as required by [RFC3046] and
[I-D.ietf-dhc-dhcpv4-relay-encapsulation], and forwards it to the [I-D.ietf-dhc-dhcpv4-relay-encapsulation], and forwards it to the
IPv6 address recorded in the CRA6ADDR sub-option, with source port 67 IPv6 address recorded in the CRA6ADDR sub-option, with source port 67
and destination port number 67. and destination port 67.
8. Security Consideration 8. Security Consideration
This mechanism may rise a new form of DHCP protocol attack. A This mechanism may rise a new form of DHCP protocol attack. A
malicious attacker in IPv6 can interference with the DHCPv4 process malicious attacker in IPv6 can interference with the DHCPv4 process
by inject fake DHCPv4-in-IPv6 messages which will be handled by TSV by injecting fake DHCPv4-in-IPv6 messages which will be handled by
or TRA. However, the damage is the same with the known DHCPv4 attack TSV or TRA. However, the damage is the same with the known DHCPv4
happened in IPv4. The only difference is the attacker and the victim attack happened in IPv4. The only difference is the attacker and the
could locate in different address families. victim could locate in different address families.
Another impact is DHCP filtering. There are firewalls today capable Another impact is DHCP filtering. There are firewalls today capable
of filtering DHCP traffic (DHCPv4 over IPv4 and DHCPv6 over IPv6 of filtering DHCP traffic (DHCPv4 over IPv4 and DHCPv6 over IPv6
packages). The DHCP messages with the new, DHCPv4-in-IPv6 style may packets). The DHCP messages with the new, DHCPv4-in-IPv6 style may
bypass these firewalls. Nevertheless it is not difficult for them to bypass these firewalls. Nevertheless it is not difficult for them to
make some slight modification and adapt to the new DHCPv4 message make some slight modification and adapt to the new DHCPv4 message
pattern. pattern.
9. IANA Consideration 9. IANA Consideration
IANA is requested to assign one new sub-option code from the registry IANA is requested to assign one new sub-option code from the registry
of DHCP Agent Sub-Option Codes maintained in of DHCP Agent Sub-Option Codes maintained in
http://www.iana.org/assignments/bootp-dhcp-parameters. This sub- http://www.iana.org/assignments/bootp-dhcp-parameters. This sub-
option code will be assigned to the Client Relay Agent IPv6 Address option code will be assigned to the Client Relay Agent IPv6 Address
skipping to change at page 10, line 28 skipping to change at page 10, line 38
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007. Problem Statement", RFC 4925, July 2007.
[RFC6842] Swamy, N., Halwasia, G., and P. Jhingran, "Client [RFC6842] Swamy, N., Halwasia, G., and P. Jhingran, "Client
Identifier Option in DHCP Server Replies", RFC 6842, Identifier Option in DHCP Server Replies", RFC 6842,
January 2013. January 2013.
11.2. Informative References 11.2. Informative References
[I-D.ietf-dhc-dhcpv4-over-dhcpv6]
Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
Farrer, "DHCPv4 over DHCPv6 Transport",
draft-ietf-dhc-dhcpv4-over-dhcpv6-02 (work in progress),
October 2013.
[I-D.ietf-dhc-v4configuration]
Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration
Over IPv6 Only Networks",
draft-ietf-dhc-v4configuration-02 (work in progress),
September 2013.
[I-D.ietf-softwire-public-4over6] [I-D.ietf-softwire-public-4over6]
Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public
IPv4 over IPv6 Access Network", IPv4 over IPv6 Access Network",
draft-ietf-softwire-public-4over6-10 (work in progress), draft-ietf-softwire-public-4over6-10 (work in progress),
July 2013. July 2013.
Appendix A. Motivation for selecting this particular solution Appendix A. Motivation for selecting this particular solution
We considered three possible solutions to the problem of configuring We considered three possible solutions to the problem of configuring
IPv4 addresses on an IPv6 network. IPv4 addresses on an IPv6 network.
skipping to change at page 12, line 13 skipping to change at page 12, line 36
easiest to specify and easiest to implement. easiest to specify and easiest to implement.
Appendix B. Discussion on One Host Retrieving Multiple Addresses Appendix B. Discussion on One Host Retrieving Multiple Addresses
through One CRA through One CRA
This document is written with the intention of supporting a use case This document is written with the intention of supporting a use case
where a single DHCP client is configuring a single tunnel endpoint where a single DHCP client is configuring a single tunnel endpoint
per physical link. The technique described in this document could be per physical link. The technique described in this document could be
used by a host needing to configure more than one tunnel endpoint on used by a host needing to configure more than one tunnel endpoint on
the same physical link, i.e., to retrieve multiple addresses through the same physical link, i.e., to retrieve multiple addresses through
the same CRA. However, the following additional behavior is required the same CRA.
to support this case.
DHCP server implementing this specification implements Client DHCP server implementing this specification implements Client
Identifier Option in DHCP server replies [RFC6842]. Identifier Option in DHCP server replies [RFC6842].
In general this specification is intended not to require modification In general this specification is intended not to require modification
of DHCP clients. However, DHCP clients being used to configure of DHCP clients. However, DHCP clients being used to configure
multiple tunnel endpoints have to be modified; otherwise there is no multiple tunnel endpoints have to be modified; otherwise there is no
way for such DHCP clients to differentiate between DHCP responses. way for such DHCP clients to differentiate between DHCP responses.
Therefore, in such case, the DHCP client using this specification Therefore, in such case, the DHCP client using this specification
uses a different client identifier for each tunnel endpoint being uses a different client identifier for each tunnel endpoint being
skipping to change at line 572 skipping to change at page 14, line 21
Email: jianping@cernet.edu.cn Email: jianping@cernet.edu.cn
Ted Lemon Ted Lemon
Nominum, Inc. Nominum, Inc.
2000 Seaport Blvd 2000 Seaport Blvd
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Phone: +1-650-381-6000 Phone: +1-650-381-6000
Email: mellon@nominum.com Email: mellon@nominum.com
Qi Sun
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: sunqi@csnet1.cs.tsinghua.edu.cn
 End of changes. 24 change blocks. 
42 lines changed or deleted 68 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/