draft-ietf-dhc-dhcpv4-over-ipv6-00.txt   draft-ietf-dhc-dhcpv4-over-ipv6-01.txt 
Network Working Group Y. Cui Network Working Group Y. Cui
Internet-Draft P. Wu Internet-Draft P. Wu
Intended status: Standards Track J. Wu Intended status: Standards Track J. Wu
Expires: June 2, 2012 Tsinghua University Expires: September 13, 2012 Tsinghua University
T. Lemon T. Lemon
Nominum, Inc. Nominum, Inc.
November 30, 2011 March 12, 2012
DHCPv4 over IPv6 Transport DHCPv4 over IPv6 Transport
draft-ietf-dhc-dhcpv4-over-ipv6-00 draft-ietf-dhc-dhcpv4-over-ipv6-01
Abstract Abstract
Recently, there are demands arising for IPv4 address allocation under In IPv6 networks, there remains a need to provide IPv4 service for
IPv6 environment, especially in IPv6 transition scenarios. This some residual devices. This document describes a mechanism for
document describes the mechanism to survive DHCPv4 over IPv6 network. allocating IPv4 addresses to such devices using DHCPv4 with an IPv6
DHCPv4 messages are transported in IPv6 packets when traversing the transport. It is done by extending DHCP client and server behavior,
IPv6 network. DHCPv4 protocol behavior of the client and server is and by adding a new Relay Agent Information option to carry the IPv6
extended to support this IPv6 transport. For the relay case, a new address of the client.
suboption of the Relay Agent Information Option is defined to carry
the remote IPv6 address of the clients.
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 June 2, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 25 skipping to change at page 2, line 23
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 4
5. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . . 6 5. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . . 6
6. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . . 6 6. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . . 6
7. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 7 7. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 7
8. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . . 7 8. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . . 7
9. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 9. Security Consideration . . . . . . . . . . . . . . . . . . . . 8
10. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8 10. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
DHCPv4 [RFC2131] was not designed with IPv6 consideration. In DHCPv4 [RFC2131] was not designed with IPv6 in mind: DHCPv4 cannot
particular, DHCPv4 cannot work on the IPv6 network. However, with operate on an IPv6 network. However, as dual-stack networks become a
IPv4-IPv6 coexistence coming to reality, the demand of allocating reality, the need arises to allocate IPv4 addresses in an IPv6
IPv4 address under IPv6 environment naturally arises. To meet this environment. To meet this demand, this document extends DHCPv4 to
demand, DHCPv4 should be extended to run over the IPv6 network. 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
the end users are provisioned by the concentrator side, then the the end users are provisioned by the concentrator side, then the
provisioning process should be able to cross the IPv6 network, too. provisioning process should be able to cross the IPv6 network, too.
One such tunnel mechanism is demonstrated in One such tunnel mechanism is demonstrated in
[I-D.ietf-softwire-public-4over6]. DHCPv4 over IPv6 would be a [I-D.ietf-softwire-public-4over6]. DHCPv4 over IPv6 would be a
generic solution for this scenario. generic solution for this scenario.
skipping to change at page 3, line 33 skipping to change at page 3, line 33
Three main flavours of solutions may be considered: Three main flavours of solutions may be considered:
o Use DHCPv6 instead of DHCPv4, to provision IPv4-related o Use DHCPv6 instead of DHCPv4, to provision IPv4-related
connectivity. In DHCPv6, the provisioned IPv4 address can be connectivity. In DHCPv6, the provisioned IPv4 address can be
embedded into IPv6 address, or carried within a new option. Along embedded into IPv6 address, or carried within a new option. Along
with that, dedicated options are needed to convey IPv4-related with that, dedicated options are needed to convey IPv4-related
information, such as the IPv4 address of DNS server, NTP server, information, such as the IPv4 address of DNS server, NTP server,
etc. Therefore it will put a certain amount of IPv6-unrelated etc. Therefore it will put a certain amount of IPv6-unrelated
information into DHCPv6 protocol. information into DHCPv6 protocol.
o Use DHCPv4 and tunnel DHCPv4-in-IPv4 packets over IPv6. Unlike o Use DHCPv4 and tunnel DHCPv4-in-IPv4 messages over IPv6. Unlike
the previous approach where DHCPv6 is used for both IPv4 and IPv6 the previous approach where DHCPv6 is used for both IPv4 and IPv6
connectivity, this approach consists in preserving the separation connectivity, this approach consists in preserving the separation
between IPv4 and IPv6 connectivity information. It allows to between IPv4 and IPv6 connectivity information. It allows to
maintain the IPv4 service without major modification of IPv6- maintain the IPv4 service without major modification of IPv6-
related provisioning resources, and sustains DHCPv4 to be the related provisioning resources, and sustains DHCPv4 to be the
IPv4-related information carrier. However, this approach enforces IPv4-related information carrier. However, this approach enforces
an IPv4-in-IPv6 tunnel onto DHCP, and requires extra efforts to an IPv4-in-IPv6 tunnel on DHCP, and requires extra efforts to
maintain tunnel endpoint information for encapsulation use. maintain tunnel endpoint information for encapsulation use.
o Use DHCPv4 and extend it to work over IPv6 transport. This o Use DHCPv4 and extend it to work over IPv6 transport. Instead of
flavour uses IPv6 directly for DHCP packet transport instead of relying on IPv4-in-IPv6 tunnel, this flavour uses IPv6 directly
relying on IPv4-in-IPv6 tunnel, and it keeps the advantage of for DHCP message transport, and it keeps the advantage of
separation with IPv6 connectivity information. This document separation with IPv6 connectivity information. This document
focuses on this flavour. The document will define the extensions focuses on this flavour. The document will define the extensions
of DHCPv4 protocol behavior, as well as a new suboption of the of DHCPv4 protocol behavior, as well as a new suboption of the
Relay Agent Information Option, to fully support DHCPv4 over IPv6. Relay Agent Information Option, to fully support DHCPv4 over IPv6.
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].
skipping to change at page 4, line 19 skipping to change at page 4, line 19
This document makes use of the following terms: This document makes use of the following terms:
o DHCPv4: IPv4 Dynamic Host Configuration Protocol [RFC2131]. o DHCPv4: IPv4 Dynamic Host Configuration Protocol [RFC2131].
o Client Relay Agent(CRA): a special DHCPv4 Relay Agent that sits on o Client Relay Agent(CRA): a special DHCPv4 Relay Agent that sits on
the same, IPv6-accessable host with the DHCPv4 client. CRA works the same, IPv6-accessable host with the DHCPv4 client. CRA works
as a "bridge" between DHCPv4 client and the IPv6 network, to as a "bridge" between DHCPv4 client and the IPv6 network, to
convert between IPv4 transport and IPv6 transport. convert between IPv4 transport and IPv6 transport.
o IPv6-Transport Server(TSV): a DHCPv4 Server that support supports o IPv6-Transport Server(TSV): a DHCPv4 Server that supports IPv6
IPv6 transport. TSV can listen on IPv6 for incoming DHCPv4 transport. TSV can listen on IPv6 for incoming DHCPv4 messages,
messages, and send DHCPv4 messages in IPv6 packets. and send DHCPv4 messages in IPv6 packets.
o IPv6-Transport Relay Agent(TRA): a DHCPv4 Relay Agent that o IPv6-Transport Relay Agent(TRA): a DHCPv4 Relay Agent that
supports IPv6 transport. TRA sits on a machine which has both supports IPv6 transport. TRA sits on a machine which has both
IPv6 and IPv4 connectivity, and relays DHCP packets between CRA IPv6 and IPv4 connectivity, and relays DHCP messages between CRA
and normal DHCPv4 server. and normal DHCPv4 server.
o Client Relay Agent IPv6 Address Sub-option(6ADDR suboption): a new o Client Relay Agent IPv6 Address Sub-option(CRA6ADDR suboption): a
suboption of DHCP Relay Agent Information Option [RFC3046] defined new suboption of DHCP Relay Agent Information Option [RFC3046]
in this document. 6ADDR suboption is used by TRA to carry the IPv6 defined in this document. CRA6ADDR suboption is used by TRA to
address of a CRA. carry the IPv6 address of a CRA.
4. Protocol Summary 4. Protocol Summary
The scenario for DHCPv4 over IPv6 transport is shown in Figure 1. The scenario for DHCPv4 over IPv6 transport is shown in Figure 1.
DHCPv4 clients and DHCPv4 server/relay are separated by an IPv6 DHCPv4 clients and DHCPv4 server/relay are separated by an IPv6
network in the middle. DHCP messages between a client and the network in the middle. DHCP messages between a client and the
server/relay cannot naturally be forwarded to each other because they server/relay cannot naturally be forwarded to each other because they
are by default IPv4 UDP packets, either unicast or broadcast. To are by default IPv4 UDP packets, either unicast or broadcast. To
bridge this gap, both the client side and the server/relay side bridge this gap, both the client side and the server/relay side
should enable DHCPv4 over IPv6 transport. To be more precise, they should enable DHCPv4 over IPv6 transport. More precisely, they
shoudl support delivering and receiving DHCP messages in IPv6 UDP should support delivering and receiving DHCP messages in IPv6 UDP
packets and thereby traverse the IPv6 network. packets and thereby traverse the IPv6 network.
On the client side, a special relay agent called Client Relay Agent On the client side, a special relay agent called Client Relay Agent
is placed on the same machine with the client. CRA is used to relay is placed on the same machine with the client. CRA is used to relay
DHCP messages from the client to the server, and from the server to DHCP messages from the client to the server, and from the server to
the client. CRA sends DHCPv4 messages to the server through unicast the client. CRA sends DHCPv4 messages to the server through unicast
IPv6 UDP, and receives unicast IPv6 UDP packets with the DHCPv4 IPv6 UDP, and receives unicast IPv6 UDP packets with the DHCPv4
messages from the server. By using CRA, no extension is required on messages from the server. By using CRA, no extension is required on
the DHCP client. the DHCP client.
skipping to change at page 5, line 33 skipping to change at page 5, line 33
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 will become a little more with a server directly, the situation will become a little more
complicated. Besides the IPv6 communication with CRA, TRA also complicated. Besides the IPv6 communication with CRA, TRA also
communicates with a regular DHCPv4 server through IPv4. Therefore, communicates with a regular DHCPv4 server through IPv4. Therefore,
when TRA relays DHCP messages between a CRA and the DHCPv4 server, it when TRA relays DHCP messages between a CRA and the DHCPv4 server, it
receives DHCP message from the CRA in IPv6 and sends it to the server receives DHCP message from the CRA in IPv6 and sends it to the server
in IPv4, while receives DHCP message from the server in IPv4 and in IPv4, while receives DHCP message from the server in IPv4 and
sends it to the CRA in IPv6. TRA has to use the DHCP Relay Agent sends it to the CRA in IPv6. TRA has to use the DHCP Relay Agent
Information Option(Option 82) to record the IPv6 address of a CRA, Information Option(Option 82) to record the IPv6 address of a CRA,
which will be used as forwarding destination when relaying DHCP a which will be used as forwarding destination when relaying a DHCP
message from the server. Since Option 82 doesn't has an existing message from the server. Since Option 82 doesn't have an existing
suboption that fits in the case, this document defines a new Client suboption that fits in the case, this document defines a new Client
Relay Agent IPv6 Address Sub-option. Relay Agent IPv6 Address Sub-option.
+------+ +------+ +------+ +------+
|client| IPv6 network |TSV | |client| IPv6 network |TSV |
|+CRA |----------------| | |+CRA |----------------| |
+------+ +------+ +------+ +------+
(a)client--server case (a)client--server case
+------+ +------+ +------+ +------+ +------+ +------+
|client| IPv6 network |TRA | IPv4 network |server| |client| IPv6 network |TRA | IPv4 network |server|
|+CRA |----------------| |--------------| | |+CRA |----------------| |--------------| |
+------+ +------+ +------+ +------+ +------+ +------+
(b)client--relay--server case (b)client--relay--server case
Figure 2 Protocol Summary Figure 2 Protocol Summary
5. Client Relay Agent IPv6 Address Sub-option 5. Client Relay Agent IPv6 Address Sub-option
This suboption MUST be added by a DHCPv4 TRA. It encodes the IPv6 This suboption MUST be added by a DHCPv4 TRA. It encodes the IPv6
address of the host from which a DHCPv4-in-IPv6 CRA-to-TRA packet was address of the host from which a DHCPv4-in-IPv6 CRA-to-TRA message
received. It is intended for the TRA to relay DHCPv4 replies back to was received. It is intended for the TRA to relay DHCPv4 replies
the proper CRA. To be more specific, the TRA uses the IPv6 address back to the proper CRA. To be more specific, the TRA uses the IPv6
encoded in this suboption as the destination IPv6 address when address encoded in this suboption as the destination IPv6 address
relaying a DHCPv4 reply to IPv6 network. when relaying a DHCPv4 reply to IPv6 network.
The CRA IPv6 address MUST be unique in the IPv6 domain. The CRA IPv6 address MUST be unique in the IPv6 domain.
The 6ADDR suboption has a fixed length of 18 octets. The SubOpt code The CRA6ADDR suboption has a fixed length of 18 octets. The SubOpt
is tbd by IANA, the length field should be 16, and the following 16 code is tbd by IANA, the length field should be 16, and the following
octets contain the CRA IPv6 address. 16 octets contain the CRA IPv6 address.
DHCP servers MAY use this suboption to select parameters specific to DHCP servers MAY use this suboption to select parameters specific to
particular hosts. Servers MAY parse this suboption and extract the particular hosts. Servers MAY parse this suboption and extract the
semantic of IPv6 address. semantic of IPv6 address.
SubOpt Len Agent Remote ID SubOpt Len Agent Remote ID
+------+------+------+------+------+- -+------+ +------+------+------+------+------+- -+------+
| tbd | 16 | a1 | a2 | a3 | ... | a16 | | tbd | 16 | a1 | a2 | a3 | ... | a16 |
+------+------+------+------+------+- -+------+ +------+------+------+------+------+- -+------+
skipping to change at page 6, line 47 skipping to change at page 6, line 47
between regular client and TSV/TRA. The communication between CRA between regular client and TSV/TRA. The communication between CRA
and the client happens within the machine using IPv4, and the and the client happens within the machine using IPv4, and the
communication between CRA and TSV/TRA happens on the IPv6 network communication between CRA and TSV/TRA happens on the IPv6 network
using IPv6. using IPv6.
A CRA is configured with one or more IPv6 addresses of TSV/TRA. This A CRA is configured with one or more IPv6 addresses of TSV/TRA. This
configuration is provided before DHCPv4 process, for example through configuration is provided before DHCPv4 process, for example through
DHCPv6 option, or by some other mechanisms depending on the DHCPv6 option, or by some other mechanisms depending on the
application scenarios. application scenarios.
A CRA listens for DHCP packets on IPv4 UDP port 67. When it receives A CRA listens for DHCP messages on IPv4 UDP port 67. When it
from IPv4 any DHCP packet with bootp op field = 1, it forwards the receives from IPv4 any DHCP message with bootp op field = 1, it
packet using the standard DHCP relay agent format, but over UDPv6, forwards the message using the standard DHCP relay agent format, but
with source port 67 and destination port 67. Here the CRA MUST NOT over UDPv6, with source port 67 and destination port 67. Here the
include an option 82 or modify the giaddr field of the DHCP packet. CRA MUST NOT include an option 82 or modify the giaddr field of the
The CRA forwards the packet to each of the DHCP server or relay agent DHCP message. The CRA forwards the message to each of the DHCP
with which it is configured. The CRA MUST use a global IPv6 address server or relay agent with which it is configured. The CRA MUST use
if it has one. a global IPv6 address if it has one.
A CRA also listens for DHCP packets on IPv6 UDP port 68. When it A CRA also listens for DHCP messages on IPv6 UDP port 68. When it
receives from IPv6 any DHCP packet with bootp op field = 2, the CRA receives from IPv6 any DHCP message with bootp op field = 2, the CRA
checks to see if the packet contains option 82, and if so, it drops checks to see if the message contains option 82, and if so, it
the packet. Otherwise, it delivers the packet to the DHCP client discards the message. Otherwise, it delivers the message to the DHCP
using IPv4. client using IPv4.
7. IPv6-Transport Server Behavior 7. IPv6-Transport Server Behavior
To support IPv6 transport, the behavior of DHCPv4 server should be To support IPv6 transport, the behavior of DHCPv4 server should be
extended. The IPv6-Transport Server can listen on IPv6 port 67 for extended. The IPv6-Transport Server can listen on IPv6 port 67 for
DHCPv4 packets, and send DHCPv4 packets through IPv6. DHCPv4 messages, and send DHCPv4 messages through IPv6.
A TSV listens for DHCP packets on IPv6 UDP port 67. When it receives A TSV listens for DHCP messages on IPv6 UDP port 67. When it
from IPv6 a DHCP packet, it MUST record the IPv6 source address of receives from IPv6 a DHCP message, it MUST record the IPv6 source
that packet and retain it as the return address of the packet. That address of that message and retain it as the return address of the
is to say, when sometime later the TSV responds to this packet, it message. That is to say, when sometime later the TSV responds to
MUST send the reply packet to the IPv6 return address retained this message, it MUST send the reply message to the IPv6 return
earlier. The rest of TSV DHCP process is the same with normal DHCPv4 address retained earlier, with destination port 68. When the TSV
server. A TSV can also listen on IPv4 UDP port 67 like a normal receives an DHCP message with a CRA6ADDR option, the TSV handles it
DHCPv4 server, and process normally when receives IPv4 DHCPv4 packet. following the standard option 82 proceudure defined in [RFC3046].
The rest of TSV DHCP process is the same with normal DHCPv4 server.
A TSV can also listen on IPv4 UDP port 67 like a normal DHCPv4
server, and process normally when receives IPv4 DHCPv4 message.
This document places no new requirements on DHCPv4 servers that do This document places no new requirements on DHCPv4 servers that do
not listen on UDPv6--in order to use an IPv4-only DHCPv4 server not listen on UDPv6--in order to use an IPv4-only DHCPv4 server
through an IPv6 connection, a TRA is required. through an IPv6 connection, a TRA is required.
8. IPv6-Transport Relay Agent Behavior 8. IPv6-Transport Relay Agent Behavior
An IPv6-Transport Relay Agent sits between IPv6 network and IPv4 An IPv6-Transport Relay Agent sits between IPv6 network and IPv4
network, and relays DHCPv4 message between CRAs and IPv4-only DHCPv4 network, and relays DHCPv4 message between CRAs and IPv4-only DHCPv4
server. The communication between CRAs and the TRA uses IPv6, while server. The communication between CRAs and the TRA uses IPv6, while
the communication between TRA and server uses IPv4. A TRA listens on the communication between TRA and server uses IPv4. A TRA listens on
IPv6 UDP port 67 for DHCP packets with bootp op field = 1, as well as IPv6 UDP port 67 for DHCP messages with bootp op field = 1, as well
IPv4 UDP port 68 for DHCP packets with bootp op field = 2. as IPv4 UDP port 68 for DHCP messages with bootp op field = 2.
When relaying a DHCP message from CRA to server, TRA MUST add an When relaying a DHCP message from CRA to server, TRA MUST add an
option 82 with a 6ADDR suboption. This suboption contains the IPv6 option 82 with a CRA6ADDR suboption. This suboption contains the
source address of the message (the CRA's IPv6 address) which is IPv6 source address of the message (the CRA's IPv6 address) which is
retained when the message is received in IPv6. The TRA MUST also retained when the message is received in IPv6. The TRA MUST also
store the IPv4 address of itself in the giaddr field of the DHCP store the IPv4 address of itself in the giaddr field of the DHCP
message. The TRA MAY include a Link Selection Suboption [RFC3527] to message. The TRA MAY include a Link Selection Suboption [RFC3527] to
indicate to the DHCP server which link to use when choosing an IP indicate to the DHCP server which link to use when choosing an IP
address. address.
When a TRA receives a DHCP message from the DHCP server, if the When receiving a DHCP message from the DHCP server, if the option 82
packet contains no 6ADDR suboption, the TRA discards the packet. in the message contains no CRA6ADDR suboption, the TRA MUST discard
Otherwise, it processes it as required by [RFC3046], and forwards it the message. Otherwise, it processes it as required by [RFC3046],
to the IPv6 address recorded in the 6ADDR suboption. and forwards it to the IPv6 address recorded in the CRA6ADDR
suboption, with source port 67 and destination port number 68. TRA
SHOULD drop DHCPv4-over-IPv6 traffic that is not originated from
configured server address.
9. Security Consideration 9. Security Consideration
This specification raises no particular security issues to the DHCPv4 This mechanism may rise a new form of DHCP protocol attack. A
protocol model. malicious attacker in IPv6 can interference with the DHCPv4 process
by inject fake DHCPv4-in-IPv6 messages which will be handled by TSV
or TRA. However, the damage is the same with the known DHCPv4 attack
happened in IPv4. The only difference is the attacker and the victim
could locate in different address families.
Another impact is DHCP filtering. There are firewalls today capable
of filtering DHCP traffic (DHCPv4 over IPv4 and DHCPv6 over IPv6
packages). The DHCP messages with the new, DHCPv4-in-IPv6 style may
bypass these firewalls. Nevertheless it is not difficult for them to
make some slight modification and adapt to the new DHCPv4 message
pattern.
10. IANA consideration 10. IANA consideration
IANA is requested to assign one new suboption code from the registry IANA is requested to assign one new suboption 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 http://www.iana.org/assignments/bootp-dhcp-parameters. This
suboption code will be assigned to the Client Relay Agent IPv6 suboption code will be assigned to the Client Relay Agent IPv6
Address Sub-option. Address Sub-option.
11. References 11. References
skipping to change at page 9, line 28 skipping to change at page 9, line 46
Phone: +86-10-6260-3059 Phone: +86-10-6260-3059
EMail: cuiyong@tsinghua.edu.cn EMail: cuiyong@tsinghua.edu.cn
Peng Wu Peng Wu
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing 100084 Beijing 100084
P.R.China P.R.China
Phone: +86-10-6278-5822 Phone: +86-10-6278-5822
EMail: peng-wu@foxmail.com EMail: pengwu.thu@gmail.com
Jianping Wu Jianping Wu
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing 100084 Beijing 100084
P.R.China P.R.China
Phone: +86-10-6278-5983 Phone: +86-10-6278-5983
EMail: jianping@cernet.edu.cn EMail: jianping@cernet.edu.cn
 End of changes. 27 change blocks. 
77 lines changed or deleted 92 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/