draft-ietf-dhc-dhcpv6-unknown-msg-01.txt   draft-ietf-dhc-dhcpv6-unknown-msg-02.txt 
DHC Working Group Y. Cui DHC Working Group Y. Cui
Internet-Draft Q. Sun Internet-Draft Q. Sun
Intended status: Standards Track Tsinghua University Updates: RFC3315 (if approved) Tsinghua University
Expires: December 28, 2013 T. Lemon Intended status: Standards Track T. Lemon
Nominum, Inc. Expires: March 29, 2014 Nominum, Inc.
June 26, 2013 September 25, 2013
Handling Unknown DHCPv6 Messages Handling Unknown DHCPv6 Messages
draft-ietf-dhc-dhcpv6-unknown-msg-01 draft-ietf-dhc-dhcpv6-unknown-msg-02
Abstract Abstract
Dynamic Host Configuration Protocol version 6 (DHCPv6) isn't specific Dynamic Host Configuration Protocol version 6 (DHCPv6) isn't specific
about handling messages with unknown types. This memo describes the about handling messages with unknown types. This memo describes the
problems and defines how a DHCPv6 function node should behave in this problems and defines how a DHCPv6 function node should behave in this
case. This document updates RFC3315. case. This document updates RFC3315.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 December 28, 2013. This Internet-Draft will expire on March 29, 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
4. Relay Agent Behavior Update . . . . . . . . . . . . . . . . . . 3 4. Relay Agent Behavior Update . . . . . . . . . . . . . . . . . . 3
4.1. Definition of a Valid Message . . . . . . . . . . . . . . . 4 4.1. Definition of a Valid Message . . . . . . . . . . . . . . . 4
4.2. Relaying a Message towards Server . . . . . . . . . . . . . 4 4.2. Relaying a Message towards Server . . . . . . . . . . . . . 4
4.3. Relaying a Message towards Client . . . . . . . . . . . . . 4 4.3. Relaying a Message towards Client . . . . . . . . . . . . . 4
5. Client and Server Behavior Update . . . . . . . . . . . . . . . 5 5. Client and Server Behavior Update . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. Contributors List . . . . . . . . . . . . . . . . . . . . . . . 6 8. Contributors List . . . . . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
Dynamic Host Configuration Protocol version 6 (DHCPv6) [RFC3315] Dynamic Host Configuration Protocol version 6 (DHCPv6) [RFC3315]
provides a framework for conveying IPv6 configuration information to provides a framework for conveying IPv6 configuration information to
hosts on a TCP/IP network. But [RFC3315] is not specific about how hosts on a TCP/IP network. But [RFC3315] is not specific about how
to deal with message with unrecognized types. This document describe to deal with message with unrecognized types. This document describe
the problems and defines the behavior of a DHCPv6 function node when the problems and defines the behavior of a DHCPv6 function node when
handling unknown DHCPv6 messages. This document updates [RFC3315]. handling unknown DHCPv6 messages. This document updates [RFC3315].
skipping to change at page 4, line 10 skipping to change at page 4, line 10
extracts the encapsulated message and sends it to the specified extracts the encapsulated message and sends it to the specified
destination address. Any message other than a Relay-reply does not destination address. Any message other than a Relay-reply does not
have such a specified destination, so it follows the default have such a specified destination, so it follows the default
forwarding path configured on the relay agent, which is always toward forwarding path configured on the relay agent, which is always toward
the server. the server.
4.1. Definition of a Valid Message 4.1. Definition of a Valid Message
Section 20.1 of [RFC3315] states that: Section 20.1 of [RFC3315] states that:
"When a relay agent receives a valid message to be relayed, it "When a relay agent receives a valid message to be relayed, it
constructs a new Relay-forward message." constructs a new Relay-forward message."
It doesn't define what a valid message is. In this document, we It doesn't define what a valid message is. In this document, we
specify the definition: the message is valid for constructing a new specify the definition as follows.
Relay-forward message if the recipient is a relay agent, the relay
agent does not identify itself as the intended recipient, and the
message is not a Relay-Reply message.
We state the definition in this way for the following reasons:
o Any message received by a client or server is clearly not a
candidate for forwarding.
o Any message received by the relay in response to a message it has The message is valid for constructing a new Relay-forward message:
sent to the server-e.g., a RECONFIGURE-REPLY message-is also not a
candidate for forwarding.
o A standards-compliant DHCP server will never send a message to a (a) if the message is a Relay-forward message, or
relay other than in response to a message from a relay, so there
should never be a case where a relay receives a message for which
it is the intended recipient, but is not able to recognize that it
is the intended recipient for the message.
o A Relay-Reply message is an encapsulation intended for the client (b) if a relay agent receives the message but the relay agent does
or for a relay agent closer to the client. It specifies a not identify itself as the target of the message, and the message
destination, and hence is never to be encapsulated and sent back is not a Relay-reply message.
to the server.
Any message that does not meet any of these criteria must therefore In the case that a new type of relay message is sent to a relay agent
be a message intended to be relayed to the DHCP server. but the relay agent doesn't recognize it, the message is put into a
Relay-forward message and sent to the server. Then the server knows
the relay agent doesn't support the new message.
4.2. Relaying a Message towards Server 4.2. Relaying a Message towards Server
If the relay agent received a Relay-forward message, Section 20.1.2 If the relay agent received a Relay-forward message, Section 20.1.2
of [RFC3315] defines the related behavior. If the relay agent of [RFC3315] defines the related behavior. If the relay agent
received messages other than Relay-forward and Relay-reply, it MUST received messages other than Relay-forward and Relay-reply, it MUST
forward them as is described in Section 20.1.1 of [RFC3315]. forward them as is described in Section 20.1.1 of [RFC3315].
4.3. Relaying a Message towards Client 4.3. Relaying a Message towards Client
If the relay agent received a Relay-reply message, it MUST unpack the If the relay agent receives a Relay-reply message, it MUST process
message and forward it as is defined in Section 20.2 of [RFC3315], the message as is defined in Section 20.2 of [RFC3315], regardless of
regardless of the message type in Relay Message Option. the type of the message encapsulated in the Relay Message Option.
5. Client and Server Behavior Update 5. Client and Server Behavior Update
There are chances that the client or server would receive DHCPv6 There are chances that the client or server would receive DHCPv6
messages with unknown types. In this case, the client or server MUST messages with unknown types. In this case, the client or server MUST
discard the unrecognized messages. discard the unrecognized messages.
6. Security Considerations 6. Security Considerations
As the relay agent will forward all unknown types of DHCPv6 messages, As the relay agent will forward all unknown types of DHCPv6 messages,
a malicious attacker can interfere with the relaying function by a malicious attacker can interfere with the relaying function by
constructing fake DHCPv6 messages with arbitrary type code. The same constructing fake DHCPv6 messages with arbitrary type code. The same
problem may happen in current DHCPv4 and DHCPv6 practice where the problem may happen in current DHCPv4 and DHCPv6 practice where the
attacker has to construct the fake DHCP message with an known type attacker has to construct the fake DHCP message with an known type
code. code.
Clients and servers that implement this specification will discard Clients and servers that implement this specification will discard
unknown DHCPv6 messages. Since RFC3315 did not specify either relay, unknown DHCPv6 messages. Since RFC3315 did not specify either relay,
client or server behavior in the presence of unknown messages, it is client or server behavior in the presence of unknown messages, it is
 End of changes. 12 change blocks. 
40 lines changed or deleted 26 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/