draft-ietf-dhc-dhcpv6-unknown-msg-07.txt   draft-ietf-dhc-dhcpv6-unknown-msg-08.txt 
DHC Working Group Y. Cui DHC Working Group Y. Cui
Internet-Draft Q. Sun Internet-Draft Q. Sun
Updates: 3315 (if approved) Tsinghua University Updates: 3315 (if approved) Tsinghua University
Intended status: Standards Track T. Lemon Intended status: Standards Track T. Lemon
Expires: September 27, 2014 Nominum, Inc. Expires: September 28, 2014 Nominum, Inc.
March 26, 2014 March 27, 2014
Handling Unknown DHCPv6 Messages Handling Unknown DHCPv6 Messages
draft-ietf-dhc-dhcpv6-unknown-msg-07 draft-ietf-dhc-dhcpv6-unknown-msg-08
Abstract Abstract
DHCPv6 is not specific about handling messages with unknown types. DHCPv6 is not specific about handling messages with unknown types.
This memo describes the problems and defines how a DHCPv6 server, This memo describes the problems and defines how a DHCPv6 server,
client or relay agent should behave when receiving unknown DHCPv6 client or relay agent should behave when receiving unknown DHCPv6
messages. This document also provides advice for authors of future messages. This document also provides advice for authors of future
documents defining new messages sent from DHCP servers to DHCP relay documents defining new messages sent from DHCP servers to DHCP relay
agents, and should be read by potential authors of such documents. agents, and should be read by potential authors of such documents.
This document updates RFC3315. This document updates RFC3315.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 September 27, 2014. This Internet-Draft will expire on September 28, 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 28 skipping to change at page 2, line 28
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Relay Agent Behavior Update . . . . . . . . . . . . . . . . . 3 4. Relay Agent Behavior Update . . . . . . . . . . . . . . . . . 3
4.1. A Valid Message for Constructing a New Relay-forward 4.1. A Valid Message for Constructing a New Relay-forward
Message . . . . . . . . . . . . . . . . . . . . . . . . . 4 Message . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Relaying a Message toward Server . . . . . . . . . . . . 4 4.2. Relaying a Message toward Server . . . . . . . . . . . . 4
4.3. Relaying a Message toward Client . . . . . . . . . . . . 5 4.3. Relaying a Message toward Client . . . . . . . . . . . . 4
5. Client and Server Behavior Update . . . . . . . . . . . . . . 5 5. Client and Server Behavior Update . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Contributors List . . . . . . . . . . . . . . . . . . . . . . 6 8. Contributors List . . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
DHCPv6 [RFC3315] provides a framework for conveying IPv6 DHCPv6 [RFC3315] provides a framework for conveying IPv6
skipping to change at page 3, line 8 skipping to change at page 3, line 8
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Problem Statement 3. Problem Statement
When a relay agent receives a message, it decides to send the message When a relay agent receives a message, it decides to send the message
either toward the server or toward the client. However, RFC 3315 either toward the server or toward the client. It decides on the
does not explicitly describe how the relay agent can determine direction to forward based on the message type. Since RFC3315 was
whether it should send a message toward the server or the client, published new message types have been defined. More such messages
although this is implied by the message definitions in RFC3315. may be defined in the future. RFC3315 does not specify the what to
do when a DHCP agent does not recognize the type of message it has
Another issue is that RFC3315 does not specify what a relay agent received. This may lead to relay agents inappropriately dropping
should do if it does not recognize a received message; the relay such messages, and to other DHCP agents inappropriately processing
agent is not required to relay the message, nor advised to drop the such messages.
message. If relaying an unknown message, the relay agent is given no
guidance about whether to send it toward the server or the client.
In addition, there is no specific requirement for dealing with In addition, there is no specific requirement for dealing with
unknown messages by the client or server in RFC3315. unknown messages by the client or server in RFC3315.
Note it is expected that most future DHCPv6 messages will not be used Note it is expected that most future DHCPv6 messages will not be used
to communicate directly with relay agents (though they may need to be to communicate directly with relay agents (though they may need to be
relayed by relay agents). relayed by relay agents).
4. Relay Agent Behavior Update 4. Relay Agent Behavior Update
skipping to change at page 4, line 20 skipping to change at page 4, line 13
constructs a new Relay-forward message." constructs a new Relay-forward message."
It does not define which types of messages are valid for constructing It does not define which types of messages are valid for constructing
Relay-Forward messages. In this document, we specify the definition Relay-Forward messages. In this document, we specify the definition
as follows. as follows.
The message is valid for constructing a new Relay-forward message: The message is valid for constructing a new Relay-forward message:
(a) if the message is a Relay-forward message, or (a) if the message is a Relay-forward message, or
(b) if the relay agent receives the message for which it does not (b) if the relay agent recognizes the message type and is not the
identify itself as the target. intended target, or
(c) if the relay agent does not recognize the message type.
New DHCP message types may be defined in future that are sent, New DHCP message types may be defined in future that are sent,
unsolicited, to relay agents. Relay agents that do not implement unsolicited, to relay agents. Relay agents that do not implement
these messages will not recognize such messages as being intended for these messages will not recognize such messages as being intended for
them. A relay agent that implements this specification will them. A relay agent that implements this specification will
therefore forward such messages to the DHCP servers to which it is therefore forward such messages to the DHCP servers to which it is
configured to relay client messages. configured to relay client messages.
At this time, no such message types have been specified. If such a At this time, no such message types have been specified. If such a
message is specified in the future, it is possible that this would message is specified in the future, it is possible that this would
 End of changes. 7 change blocks. 
18 lines changed or deleted 18 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/