draft-bellis-dnsop-session-signal-01.txt   draft-bellis-dnsop-session-signal-02.txt 
DNSOP Working Group R. Bellis DNSOP Working Group R. Bellis
Internet-Draft ISC Internet-Draft ISC
Intended status: Standards Track S. Cheshire Intended status: Standards Track S. Cheshire
Expires: January 22, 2017 Apple Inc. Expires: January 29, 2017 Apple Inc.
J. Dickinson J. Dickinson
S. Dickinson S. Dickinson
Sinodun Sinodun
A. Mankin A. Mankin
Salesforce Salesforce
T. Pusateri T. Pusateri
Unaffiliated Unaffiliated
July 21, 2016 July 28, 2016
DNS Session Signaling DNS Session Signaling
draft-bellis-dnsop-session-signal-01 draft-bellis-dnsop-session-signal-02
Abstract Abstract
The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] is explicitly The EDNS(0) Extension Mechanism for DNS [RFC6891] is explicitly
defined to only have "per-message" semantics. This document defines defined to only have "per-message" semantics. This document defines
a new Session Signaling OpCode used to carry persistent "per-session" a new Session Signaling Opcode used to carry persistent "per-session"
type-length-values (TLVs), and defines an initial set of TLVs used to type-length-values (TLVs), and defines an initial set of TLVs used to
manage session timeouts and termination. manage session timeouts and termination.
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 January 22, 2017. This Internet-Draft will expire on January 29, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 4 3.1. Session Lifecycle . . . . . . . . . . . . . . . . . . . . 4
3.2. Message Handling . . . . . . . . . . . . . . . . . . . . 4 3.2. Message Format . . . . . . . . . . . . . . . . . . . . . 5
3.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Message Handling . . . . . . . . . . . . . . . . . . . . 6
4. Mandatory TLVs . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Session Management Support TLVs . . . . . . . . . . . . . 6 4. Mandatory TLVs . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. "Not Implemented" . . . . . . . . . . . . . . . . . . 6 4.1. Session Management Support TLVs . . . . . . . . . . . . . 7
4.2. Session Management TLVs . . . . . . . . . . . . . . . . . 6 4.1.1. "Not Implemented" . . . . . . . . . . . . . . . . . . 8
4.2.1. Start Session . . . . . . . . . . . . . . . . . . . . 6 4.2. Session Management TLVs . . . . . . . . . . . . . . . . . 8
4.2.2. Terminate Session . . . . . . . . . . . . . . . . . . 6 4.2.1. Idle Timeout . . . . . . . . . . . . . . . . . . . . 8
4.2.3. Idle Timeout . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Terminate Session . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. DNS Session Signaling Opcode Registration . . . . . . . . 8 5.1. DNS Session Signaling Opcode Registration . . . . . . . . 10
5.2. DNS Session Signaling Type Codes Registry . . . . . . . . 8 5.2. DNS Session Signaling Type Codes Registry . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] is explicitly The use of transports other than UDP for DNS is being increasingly
defined to only have "per-message" semantics. This document defines specified, for example, DNS-over-TCP [RFC7766], DNS-over-TLS
a new Session Signaling OpCode used to carry persistent "per-session" [RFC7858] and recent work on DNS Push Notifications
type-length-values (TLVs), and defines an initial set of TLVs used to [I-D.ietf-dnssd-push]. Such transports frequently use persistent,
manage session timeouts and termination. long-lived sessions and therefore when using them for transporting
DNS messages it is of benefit to have a mechanism that can establish
parameters associated with those sessions, such as timeouts. In such
situations it is also advantageous to support server initiated
messages.
A further issue with EDNS(0) is that there is no standard mechanism The EDNS(0) Extension Mechanism for DNS [RFC6891] is explicitly
for a client to be able to tell whether a server has processed or defined to only have "per-message" semantics. Whilst EDNS(0) has
otherwise acted upon the individual options contained with an OPT RR. been used to signal at least one session related parameter (the EDNS
The Session Signaling OpCode therefore requires an explicit response TCP KeepAlive option [RFC7828]) the result is less than optimal due
to each request message. to the restrictions imposed by the EDNS(0) semantics and the lack of
server initiated signalling. This document defines a new Session
Signaling Opcode used to carry persistent "per-session" type-length-
values (TLVs), and defines an initial set of TLVs used to manage
session timeouts and termination.
It should be noted that the message format (see Section 3.1) does not With EDNS(0), multiple options may be packed into a single OPT RR,
conform to the standard DNS packet format. and there is no generalized mechanism for a client to be able to tell
whether a server has processed or otherwise acted upon each
individual option within the combined OPT RR. The specifications for
each individual option need to define how each different option is to
be acknowledged, if necessary.
With Session Signaling, in contrast, each Session Signaling operation
is communicated in its own separate DNS message, and the RCODE in the
response indicates the success or failure of that operation.
It should be noted that the message format for Session Signaling
operations (see Section 3.2) differs from the DNS packet format used
for standard queries and responses, in that it has a shorter header
(four octets instead of usual twelve octets).
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
"Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
The terms "initiator" and "responder" correspond respectively to the The terms "initiator" and "responder" correspond respectively to the
initial sender and subsequent receiver of a Session Signaling TLV, initial sender and subsequent receiver of a Session Signaling TLV,
regardless of which was the "client" and "server" in the usual DNS regardless of which was the "client" and "server" in the usual DNS
sense. The term "sender" may apply to either an initiator or sense.
responder.
The term "session" in the context of this document means the exchange
of DNS messages over a single connection using an end-to-end
transport protocol where:
o connections can be long-lived
o either end of the connection may initiate requests The term "sender" may apply to either an initiator or responder.
o message delivery order is guaranteed The term "session" in the context of this document means the exchange
of DNS messages using an end-to-end transport protocol where:
o it is guaranteed that the same two endpoints are in communication o The connection between client and server is persistent and
for the entire lifetime of the session. relatively long-lived (i.e. minutes or hours, rather than
seconds).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", o Either end of the connection may initiate messages to the other
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this o Messages are delivered in order
document are to be interpreted as described in [RFC2119].
3. Protocol Details 3. Protocol Details
Session Signaling messages MUST only be carried in protocols and in Session Signaling messages MUST only be carried in protocols and in
environments where a session may be established according to the environments where a session may be established according to the
definition above. Standard DNS over TCP [RFC1035], and DNS over TLS definition above. Standard DNS over TCP [RFC1035], and DNS over TLS
[RFC7858] are appropriate protocols. DNS over plain UDP is not [RFC7858] are suitable protocols. DNS over plain UDP is not
appropriate since it fails on both the bi-directional initiation appropriate since it fails on the requirement for in-order message
requirement and the message order delivery requirement. delivery, and, in the presence of NAT gateways and firewalls with
short UDP timeouts, it fails to provide a persistent bi-directional
communication channel unless an excessive amount of keepalive traffic
is used.
Session Signaling messages relate only to the specific session in Session Signaling messages relate only to the specific session in
which they are being carried. Where a middle box (e.g. a DNS proxy, which they are being carried. Where a middle box (e.g. a DNS proxy,
forwarder, or session multiplexer) is in the path the message MUST forwarder, or session multiplexer) is in the path the message MUST
NOT be blindly forwarded in either direction by that middle box. NOT be blindly forwarded in either direction by that middle box.
This does not preclude the use of these messages in the presence of a This does not preclude the use of these messages in the presence of a
NAT box that rewrites Layer 3 or Layer 4 headers but otherwise NAT box that rewrites IP-layer or transport-layer headers but
maintains the effect of a single session. otherwise maintains the effect of a single session.
A server MUST NOT initiate Session Signaling messages until a client- A client MAY attempt to initiate Session Signaling messages at any
initiated Session Signaling message is received first. This time on a connection; receiving a NOTIMP response in reply indicates
requirement is to ensure that the client does not observe unsolicited that the server does not implement Session Signaling, and the client
inbound messages until it has indicated its ability to handle them. SHOULD NOT issue further Session Signaling messages on that
connection.
Session Signaling support is therefore said to be confirmed from the A server SHOULD NOT initiate Session Signaling messages until a
client's point of view after the first session signaling TLV has been client-initiated Session Signaling message is received first, unless
sent by that client and subsequently successfully acknowledged by the in an environment where it is known in advance by other means that
server. both client and server support Session Signaling. This requirement
is to ensure that the clients that do not support Session Signaling
do not receive unsolicited inbound Session Signaling messages that
they would not know how to handle.
Use of Session Signaling by a client should be taken as an implicit 3.1. Session Lifecycle
request for a long-lived session.
3.1. Message Format A session begins when a client makes a new connection to a server.
A message containing a Session Signaling OpCode does not conform to The client may perform as many DNS operations as it wishes on the
the usual DNS message format. The 4 octet header format from newly created connection. Operations SHOULD be pipelined (i.e., the
[RFC1035] is however preserved, since that includes the message ID client doesn't need wait for a reply before sending the next
and OpCode and RCODE fields, and the QR bit that differentiates message). The server MUST act on messages in the order they are
requests from responses. received, but responses to those messages MAY be sent out of order,
if appropriate.
Each message MUST contain only a single TLV. When a server implementing this specification receives a new
connection from a client, it MUST begin by internally assigning an
initial idle timeout of 30 seconds to that connection. At both
servers and clients, the generation or reception of any complete DNS
message, including DNS requests, responses, updates, or Session
Signaling messages, resets the idle timer for that connection (see
[RFC7766]).
If, at any time during the life of the connection, half the idle-
timeout value (i.e., 15 seconds by default) elapses without any DNS
messages being sent or received on a connection, then the connection
is considered stale and the client MUST take action. When this
happens the client MUST either send at least one new message to reset
the idle timer - such as a Session Signaling Idle Timeout message
(see Section 4.2.1), or any other valid DNS message - or close the
connection.
If, at any time during the life of the connection, the full idle-
timeout value (i.e., 30 seconds by default) elapses without any DNS
messages being sent or received on a connection, then the connection
is considered delinquent and the server SHOULD forcibly terminate the
connection. For sessions over TCP (or over TLS-over-TCP), to avoid
the burden of having a connection in TIME-WAIT state, instead of
closing the connection gracefully with a TCP FIN the server SHOULD
abort the connection with a TCP RST. (In the Sockets API this is
achieved by setting the SO_LINGER option to zero before closing the
socket.)
If the client wishes to keep an idle connection open for longer than
the default duration without having to send traffic every 15 seconds,
then it uses the Session Signaling Idle Timeout message to request a
longer idle timeout (see Section 4.2.1).
A client is not required to wait until half of the idle-timeout value
before closing a connection. A client MAY close a connection at any
time, at the client's discretion, if it has no further need for the
connection at that time.
3.2. Message Format
A Session Signaling message begins with the first 4 octets of the
standard DNS message header [RFC1035], with the Opcode field set to
the Session Signaling Opcode. A Session Signaling message does not
contain the QDCOUNT, ANCOUNT, NSCOUNT and ARCOUNT fields fields used
in standard DNS queries and responses. This 4-octet header is
followed by a single Session Signaling TLV.
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| MESSAGE ID | | MESSAGE ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|QR | OpCode | Z | RCODE | |QR | Opcode | Z | RCODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | |
/ TLV-DATA / / TLV-DATA /
/ / / /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
The MESSAGE ID, QR, OpCode and RCODE fields have their usual meaning The MESSAGE ID, QR, Opcode and RCODE fields have their usual meanings
as defined in [RFC1035]. [RFC1035].
The Z bits are currently unused, and SHOULD be set to zero (0) in The Z bits are currently unused, and SHOULD be set to zero (0) in
requests and responses unless re-defined in a later specification. requests and responses unless re-defined in a later specification.
3.2. Message Handling 3.3. Message Handling
Both clients and servers may unilaterally send Session Signaling On a connection between a client and server that support Session
messages at any point in the lifetime of a session and are therefore Signaling, either end may unilaterally send Session Signaling
considered to be the initiator with respect to that message. The messages at any point in the lifetime of a session, and therefore
either client or server may be the initiator of a message. The
initiator MUST set the value of the QR bit in the DNS header to zero initiator MUST set the value of the QR bit in the DNS header to zero
(0), and the responder MUST set it to one (1). (0), and the responder MUST set it to one (1).
<<TODO: Specify behaviour on receipt of a message from an initiator
with the QR bit set to 1, etc.>>
Every Session Signaling request message MUST elicit a response (which Every Session Signaling request message MUST elicit a response (which
MUST have the same ID in the DNS message header as in the request). MUST have the same ID in the DNS message header as in the request).
In order to preserve the correct sequence of state, Session Signaling
requests MUST NOT be processed out of order.
<< RB: should the presence of a SS message create a "sequencing << RB: should the presence of a SS message create a "sequencing
point", such that all pending responses must be answered? >> point", such that all pending responses must be answered? SC: I do
not believe so. We can define an explicit SS "sequencing point"
opcode for this if necessary. >>
The RCODE value in a response uses a subset of the standard (non- The RCODE value in a response uses a subset of the standard (non-
extended) RCODE values from the IANA DNS RCODEs registry, interpreted extended) RCODE values from the IANA DNS RCODEs registry, interpreted
as follows: as follows:
+------+----------+---------------------------------+ +------+----------+---------------------------------+
| Code | Mnemonic | Description | | Code | Mnemonic | Description |
+------+----------+---------------------------------+ +------+----------+---------------------------------+
| 0 | NOERROR | TLV processed successfully | | 0 | NOERROR | TLV processed successfully |
| | | | | | | |
| 1 | FORMERR | TLV format error | | 1 | FORMERR | TLV format error |
| | | | | | | |
| 4 | NOTIMP | Session Signaling not supported | | 4 | NOTIMP | Session Signaling not supported |
| | | | | | | |
| 5 | REFUSED | TLV declined for policy reasons | | 5 | REFUSED | TLV declined for policy reasons |
+------+----------+---------------------------------+ +------+----------+---------------------------------+
3.3. TLV Format 3.4. TLV Format
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| SESSION-TYPE | | SSOP-TYPE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| SESSION-LENGTH | | SSOP-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | |
/ SESSION-DATA / / SSOP-DATA /
/ / / /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
SESSION-TYPE: A 16 bit field in network order giving the type of the SSOP-TYPE: A 16 bit field in network order giving the type of the
current Session Signaling TLV per the IANA DNS Session Signaling current Session Signaling TLV per the IANA DNS Session Signaling
Type Codes Registry. Type Codes Registry.
SESSION-LENGTH: A 16 bit field in network order giving the size in << SC: I changed SESSION-TYPE to SSOP-TYPE because to me SESSION-TYPE
octets of SESSION-DATA. read as "type of session" which it is not. It is Session Signaling
Operation Type, Session Signaling Operation Length, Session Signaling
Operation Data. >>
SESSION-DATA: Type-code specific. SSOP-LENGTH: A 16 bit field in network order giving the size in
octets of SSOP-DATA.
SSOP-DATA: Type-code specific.
4. Mandatory TLVs 4. Mandatory TLVs
4.1. Session Management Support TLVs 4.1. Session Management Support TLVs
4.1.1. "Not Implemented" 4.1.1. "Not Implemented"
Since the "NOTIMP" RCODE is required to indicate lack of support for Since the "NOTIMP" RCODE in the DNS message header is used to
the Session Signaling OpCode itself, the "Not Implemented" TLV (0) indicate lack of support for the Session Signaling Opcode itself, a
MUST be returned in response to a TLV that is not implemented by the different mechanism is used to indicate lack of support of a specific
responder. SSOP-TYPE. If a server that supports Session Signaling receives a
Session Signaling query message (QR bit zero) with an SSOP-TYPE it
does not support, it returns a response message (QR bit one)
containing a single Session Signaling SSOP-NOTIMP TLV (0). The
MESSAGE ID in the message header serves to tell the client which of
its requests was not understood.
This TLV has no SESSION-DATA. The SSOP-NOTIMP TLV has no SSOP-DATA.
4.2. Session Management TLVs 4.2. Session Management TLVs
4.2.1. Start Session 4.2.1. Idle Timeout
The Start Session TLV (1) SHOULD be used by a client to indicate
support for Session Signaling. It MUST NOT be initiated by a server.
It is not required that this TLV be used in every session - any valid
client-initiated TLV will suffice to initiate Session Signaling
support. The intention of this TLV is to provide a suitable "No-Op"
TLV to permit Session Signaling support to be negotiated without
carrying any other information.
This TLV has no SESSION-DATA.
<< RB: this could perhaps also be used as a real "no-op" message to
provide application-level keep-alive pings >>
4.2.2. Terminate Session The Idle Timeout TLV (1) is be used by a client to reset a
connection's idle timer, and at the same time to request what the
idle timeout should be from this point forward in the connection.
The Terminate Session TLV (2) MAY be sent by a server to request that The Idle Timeout TLV also MAY be initiated by a server, to
the client terminate the session. It MUST NOT be initiated by a unilaterally inform the client of a new idle timeout this point
client. forward in this connection.
The client SHOULD terminate the session as soon as possible, but MAY It is not required that the Idle Timeout TLV be used in every
wait for any inflight queries to be answered. It MUST NOT initiate session. While many Session Signaling operations (such as DNS Push
any new requests over the existing session. Notifications [I-D.ietf-dnssd-push]) will be used in conjunction with
a long-lived connection, this is not required, and in some cases the
default 30-second timeout may be perfectly appropriate.
The SESSION-DATA is as follows: The SSOP-DATA for the the Idle Timeout TLV is as follows:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| RECONNECT DELAY | | IDLE TIMEOUT |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
RECONNECT DELAY: a time value, specified as a 16 bit word in network IDLE TIMEOUT: the idle timeout for the current session, specified as
order in units of 100 milliseconds, within which the client MUST a 16 bit word in network order in units of 100 milliseconds. This
NOT establish a new session to the current server. is the timeout at which the server will forcibly terminate the
connection with a TCP RST (or equivalent for other protocols);
after half this interval the client MUST take action to either
preserve the connection, or close it if it is no longer needed.
The RECOMMENDED value is 10 seconds. << RB: text required here about In a client-initiated Session Signaling Idle Timeout message, the
default values for load balancers, etc >> IDLE TIMEOUT contains the client's requested value for the idle
timeout.
4.2.3. Idle Timeout In a server response to a client-initiated message, the IDLE TIMEOUT
contains the server's chosen value for the idle timeout, which the
client MUST respect. This is modeled after the DHCP protocol, where
the client requests a certain lease lifetime, but the server is the
ultimate authority for deciding what lease lifetime is actually
granted.
In a server-initiated Session Signaling Idle Timeout message, the
IDLE TIMEOUT unilaterally informs the client of the new idle timeout
this point forward in this connection.
In a client response to a server-initiated message, there is no SSOP-
DATA. SSOP-LENGTH is zero.
<<TODO: Specify the behaviour when a server sends a 0 IDLE TIMEOUT.>>
The Idle Timeout TLV (3) has similar intent to the EDNS TCP Keepalive The Idle Timeout TLV (3) has similar intent to the EDNS TCP Keepalive
Option [RFC7828]. It is used by a server to tell the client how long Option [RFC7828]. A client/server pair that supports Session
it may leave the current session idle for. a client. The definition Signaling MUST NOT use the EDNS TCP KeepAlive option within any
of an idle session is as specified in [RFC7766]. message once bi-directional Session Signaling support has been
confirmed.
Messages generate by the client have no SESSION-DATA (whether in << SC: And if client or server does use EDNS TCP Keepalive, then
requests or responses). A client-initiated Idle Timeout TLV allows other end should... close connection? Silently ignore? >>
the client to request the current timeout value, whereas a server-
initiated request allows the server to unilaterally update the
current timeout value.
Messages generated by the server contain SESSION-DATA as follows: 4.2.2. Terminate Session
There may be rare cases where a server is overloaded and wishes to
shed load. If the server simply closes connections, the likely
behaviour of clients is to detect this as a network failure, and
reconnect.
To avoid this reconnection implosion, the server sends a Terminate
Session TLV (2) to inform the client of the overload situation.
After sending a Terminate Session TLV the server MUST NOT send any
further messages on the connection.
The Terminate Session TLV (2) MUST NOT be initiated by a client.
<<TODO: Specify behaviour if the Terminate Session TLV is initiated
by a client.>>
Upon receipt of the Terminate Session TLV (2) the client MUST make
note of the reconnect delay for this server, and then immediately
close the connection.
The SSOP-DATA is as follows:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| IDLE TIMEOUT | | RECONNECT DELAY |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
IDLE TIMEOUT: the idle timeout for the current session, specified as RECONNECT DELAY: a time value, specified as a 16 bit word in network
a 16 bit word in network order in units of 100 milliseconds. order in units of 100 milliseconds, within which the client MUST
NOT establish a new session to the current server.
The client SHOULD terminate the current session if it remains idle
for longer than the specified timeout (and MAY of course terminate
the session earlier). The server MAY unilaterally terminate the
connection at any time, but SHOULD allow the client to keep the
connection open if further messages are received before the idle
timeout expires.
A client / server pair that supports Session Signaling MUST NOT use The RECOMMENDED value is 10 seconds. << RB: text required here about
the EDNS TCP KeepAlive option within any message once bi-directional default values for load balancers, etc >>
Session Signaling support has been confirmed.
5. IANA Considerations 5. IANA Considerations
5.1. DNS Session Signaling Opcode Registration 5.1. DNS Session Signaling Opcode Registration
IANA are directed to assign the value TBD for the Session Signaling IANA are directed to assign the value TBD for the Session Signaling
OpCode in the DNS OpCodes Registry. Opcode in the DNS OpCodes Registry.
5.2. DNS Session Signaling Type Codes Registry 5.2. DNS Session Signaling Type Codes Registry
IANA are directed to create the DNS Session Signaling Type Codes IANA are directed to create the DNS Session Signaling Type Codes
Registry, with initial values as follows: Registry, with initial values as follows:
+-----------+--------------------------------+----------+-----------+ +-----------+--------------------------------+----------+-----------+
| Type | Name | Status | Reference | | Type | Name | Status | Reference |
+-----------+--------------------------------+----------+-----------+ +-----------+--------------------------------+----------+-----------+
| 0 | Not implemented | | RFC-TBD1 | | 0 | SSOP-NOTIMP | Standard | RFC-TBD1 |
| | | | |
| 1 | Start Session | Standard | RFC-TBD1 |
| | | | | | | | | |
| 2 | Terminate Session | Standard | RFC-TBD1 | | 1 | SSOP-Keepalive | Standard | RFC-TBD1 |
| | | | | | | | | |
| 3 | Idle Timeout | Standard | RFC-TBD1 | | 2 | SSOP-Terminate | Standard | RFC-TBD1 |
| | | | | | | | | |
| 4 - 63 | Unassigned, reserved for | | | | 3 - 63 | Unassigned, reserved for | | |
| | session management TLVs | | | | | session management TLVs | | |
| | | | | | | | | |
| 64 - | Unassigned | | | | 64 - | Unassigned | | |
| 63487 | | | | | 63487 | | | |
| | | | | | | | | |
| 63488 - | Reserved for local / | | | | 63488 - | Reserved for local / | | |
| 64511 | experimental use | | | | 64511 | experimental use | | |
| | | | | | | | | |
| 64512 - | Reserved for future expansion | | | | 64512 - | Reserved for future expansion | | |
| 65535 | | | | | 65535 | | | |
skipping to change at page 9, line 39 skipping to change at page 12, line 22
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<http://www.rfc-editor.org/info/rfc7766>. <http://www.rfc-editor.org/info/rfc7766>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/ edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/
RFC7828, April 2016, RFC7828, April 2016,
<http://www.rfc-editor.org/info/rfc7828>. <http://www.rfc-editor.org/info/rfc7828>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-dnssd-push]
Pusateri, T. and S. Cheshire, "DNS Push Notifications",
draft-ietf-dnssd-push-08 (work in progress), July 2016.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <http://www.rfc-editor.org/info/rfc7858>. 2016, <http://www.rfc-editor.org/info/rfc7858>.
Authors' Addresses Authors' Addresses
Ray Bellis Ray Bellis
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
950 Charter Street 950 Charter Street
Redwood City CA 94063 Redwood City CA 94063
USA USA
Phone: +1 650 423 1200 Phone: +1 650 423 1200
Email: ray@isc.org Email: ray@isc.org
Stuart Cheshire Stuart Cheshire
 End of changes. 64 change blocks. 
159 lines changed or deleted 266 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/