draft-ietf-dhc-dhcpv6-unknown-msg-06.txt   draft-ietf-dhc-dhcpv6-unknown-msg-07.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 14, 2014 Nominum, Inc. Expires: September 27, 2014 Nominum, Inc.
March 13, 2014 March 26, 2014
Handling Unknown DHCPv6 Messages Handling Unknown DHCPv6 Messages
draft-ietf-dhc-dhcpv6-unknown-msg-06 draft-ietf-dhc-dhcpv6-unknown-msg-07
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 14, 2014. This Internet-Draft will expire on September 27, 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 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Relaying a Message toward Server . . . . . . . . . . . . 5 4.2. Relaying a Message toward Server . . . . . . . . . . . . 4
4.3. Relaying a Message toward Client . . . . . . . . . . . . 5 4.3. Relaying a Message toward Client . . . . . . . . . . . . 5
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
skipping to change at page 4, line 20 skipping to change at page 4, line 20
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 is not the (b) if the relay agent receives the message for which it does not
target according to the message type. identify itself as the target.
New DHCP message types may be defined in future that are intended to
convey information from DHCP servers to relay agents. Relay agents
that do not implement these messages will not recognize that such
messages are intended for them. A relay agent that implements this
specification will necessarily forward such messages to the DHCP
servers to which it is configured to relay client messages.
At this time, no messages of this variety have been specified. If
such a message is specified in the future, the specification could
include text something like the following:
DHCP servers that send this new message type MAY, when they receive New DHCP message types may be defined in future that are sent,
a relayed message of this type, mark the relay agent to which the unsolicited, to relay agents. Relay agents that do not implement
message was sent as not implementing messages of this type. In these messages will not recognize such messages as being intended for
this case, the DHCP server MAY implement a strategy of probing the them. A relay agent that implements this specification will
relay agent occasionally to see if it has been updated. therefore forward such messages to the DHCP servers to which it is
configured to relay client messages.
However, this is not strictly necessary, since DHCP does not provide At this time, no such message types have been specified. If such a
a signaling message for rejecting unexpected message types, and message is specified in the future, it is possible that this would
therefore DHCP servers are not expected to respond to such messages. result in needless load on DHCP servers. If such a message type is
defined in a future specification, authors may need to consider some
strategy for identifying non-conforming relays and not sending such
messages to them.
Documents specifying new message types should use different types for However, since DHCP servers do not respond to unknown messages, this
communicating *to* relay agents than are used for communicating is unlikely to create significant load, and therefore is likely to be
*from* relay agents, so that no confusion can occur where a message unnecessary.
sent to a relay agent is sent back to the DHCP server, which then
tries to process it as if it came from a relay agent.
4.2. Relaying a Message toward Server 4.2. Relaying a Message toward Server
If the relay agent receives a Relay-forward message, Section 20.1.2 If the relay agent receives a Relay-forward message, Section 20.1.2
of [RFC3315] defines the required behavior. If the relay agent of [RFC3315] defines the required behavior. If the relay agent
receives messages other than Relay-forward and Relay-reply and the receives messages other than Relay-forward and Relay-reply and the
relay agent does not recognize its message type, it MUST forward them relay agent does not recognize its message type, it MUST forward them
as is described in Section 20.1.1 of [RFC3315]. as is described in Section 20.1.1 of [RFC3315].
4.3. Relaying a Message toward Client 4.3. Relaying a Message toward Client
 End of changes. 8 change blocks. 
31 lines changed or deleted 22 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/