draft-bellis-dnsop-session-signal-00.txt   draft-bellis-dnsop-session-signal-01.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 7, 2017 Apple Inc. Expires: January 22, 2017 Apple Inc.
J. Dickinson J. Dickinson
S. Dickinson
Sinodun Sinodun
A. Mankin A. Mankin
Salesforce
T. Pusateri T. Pusateri
Unaffiliated Unaffiliated
July 6, 2016 July 21, 2016
DNS Session Signaling DNS Session Signaling
draft-bellis-dnsop-session-signal-00 draft-bellis-dnsop-session-signal-01
Abstract Abstract
The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] is explicitly The Extension Mechanisms for DNS (EDNS(0)) [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
handle feature negotiation and to manage session timeouts and manage session timeouts and termination.
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 7, 2017. This Internet-Draft will expire on January 22, 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
skipping to change at page 2, line 17 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 3 3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 4
3.2. Message Handling . . . . . . . . . . . . . . . . . . . . 4 3.2. Message Handling . . . . . . . . . . . . . . . . . . . . 4
3.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 5
4. Mandatory TLVs . . . . . . . . . . . . . . . . . . . . . . . 5 4. Mandatory TLVs . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Feature Negotiation . . . . . . . . . . . . . . . . . . . 5 4.1. Session Management Support TLVs . . . . . . . . . . . . . 6
4.1.1. TypeCode Support . . . . . . . . . . . . . . . . . . 5 4.1.1. "Not Implemented" . . . . . . . . . . . . . . . . . . 6
4.2. Layer 4 Connection Management TLVs . . . . . . . . . . . 6 4.2. Session Management TLVs . . . . . . . . . . . . . . . . . 6
4.2.1. Terminate . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Start Session . . . . . . . . . . . . . . . . . . . . 6
4.2.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . 6 4.2.2. Terminate Session . . . . . . . . . . . . . . . . . . 6
4.2.3. Idle Timeout . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. DNS Session Signaling OpCode Registration . . . . . . . . 7 5.1. DNS Session Signaling Opcode Registration . . . . . . . . 8
5.2. DNS Session Signaling Status Codes Registry . . . . . . . 7 5.2. DNS Session Signaling Type Codes Registry . . . . . . . . 8
5.3. DNS Session Signaling Type Codes Registry . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] is explicitly The Extension Mechanisms for DNS (EDNS(0)) [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
handle feature negotiation and to manage session timeouts and manage session timeouts and termination.
termination.
A further issue with EDNS(0) is that there is no standard mechanism A further issue with EDNS(0) is that there is no standard mechanism
for a client to be able to tell whether a server has processed or for a client to be able to tell whether a server has processed or
otherwise acted upon the individual options contained with an OPT RR. otherwise acted upon the individual options contained with an OPT RR.
The Session Signaling Opcode therefore requires an explicit response The Session Signaling OpCode therefore requires an explicit response
to each TLV within a request. to each request message.
The message format (see Section 3.1) does not completely conform to It should be noted that the message format (see Section 3.1) does not
the standard DNS packet format but is designed such that existing DNS conform to the standard DNS packet format.
protocol parsers should be able to read the packet header and then
simply ignore the extra data that appears thereafter.
2. Terminology 2. Terminology
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. The term "sender" may apply to either an initiator or
responder. 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
o message delivery order is guaranteed
o it is guaranteed that the same two endpoints are in communication
for the entire lifetime of the session.
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. 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 that can guarantee that the same two endpoints are in environments where a session may be established according to the
communication for the entire lifetime of the session. definition above. Standard DNS over TCP [RFC1035], and DNS over TLS
[RFC7858] are appropriate protocols. DNS over plain UDP is not
appropriate since it fails on both the bi-directional initiation
requirement and the message order delivery requirement.
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 Layer 3 or Layer 4 headers but otherwise
maintains the effect of a single session. maintains the effect of a single session.
<< RB: OSI Layer 5 session analog? This is obviously intended for A server MUST NOT initiate Session Signaling messages until a client-
TCP "sessions" which aren't distinct from Layer 4, but is this also initiated Session Signaling message is received first. This
applicable to DNS-o-DTLS, or DNS over UDP with an EDNS cookie - I requirement is to ensure that the client does not observe unsolicited
think probably "yes" for the former, but "no" for the latter. I'm inbound messages until it has indicated its ability to handle them.
wondering whether "session" is even the right term to be using
here >> Session Signaling support is therefore said to be confirmed from the
client's point of view after the first session signaling TLV has been
sent by that client and subsequently successfully acknowledged by the
server.
Use of Session Signaling by a client should be taken as an implicit
request for a long-lived session.
3.1. Message Format 3.1. Message Format
A message containing a Session Signaling Opcode does not conform to A message containing a Session Signaling OpCode does not conform to
the usual DNS message format. The 12 octet header format from the usual DNS message format. The 4 octet header format from
[RFC1035] is preserved, but the four section count fields (QDCOUNT, [RFC1035] is however preserved, since that includes the message ID
ANCOUNT, NSCOUNT and ARCOUNT) MUST all be set to zero. and OpCode and RCODE fields, and the QR bit that differentiates
requests from responses.
A list of TLVs are used in place of the usual sections, and MUST Each message MUST contain only a single TLV.
appear immediately after the 12 octet header. The total size of the
TLVs is calculated from the value of the standard two octet framing 1 1 1 1 1 1
word minus the 12 octets of the DNS header. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| MESSAGE ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|QR | OpCode | Z | RCODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| |
/ TLV-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
The MESSAGE ID, QR, OpCode and RCODE fields have their usual meaning
as defined in [RFC1035].
The Z bits are currently unused, and SHOULD be set to zero (0) in
requests and responses unless re-defined in a later specification.
3.2. Message Handling 3.2. Message Handling
Both clients and servers may unilaterally send Session Signaling Both clients and servers may unilaterally send Session Signaling
messages at any point in the lifetime of a session and are therefore messages at any point in the lifetime of a session and are therefore
considered to be the initiator with respect to that message. The considered to be the initiator with respect to that 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).
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).
and every TLV contained within the request requires a corresponding
TLV in the response.
In order to preserve the correct sequence of state, Session Signaling In order to preserve the correct sequence of state, Session Signaling
requests MUST NOT be processed out of order. Similarly the TLVs in a requests MUST NOT be processed out of order.
message MUST be processed in the order in which they are contained in
the message, and the order of the TLVs in the response MUST
correspond with the order of the TLVs in the request.
<< 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? >>
The RCODE value in a response uses a subset of the standard (non-
extended) RCODE values from the IANA DNS RCODEs registry, interpreted
as follows:
+------+----------+---------------------------------+
| Code | Mnemonic | Description |
+------+----------+---------------------------------+
| 0 | NOERROR | TLV processed successfully |
| | | |
| 1 | FORMERR | TLV format error |
| | | |
| 4 | NOTIMP | Session Signaling not supported |
| | | |
| 5 | REFUSED | TLV declined for policy reasons |
+------+----------+---------------------------------+
3.3. TLV Format 3.3. 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-STATUS | SESSION-TYPE | | SESSION-TYPE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| SESSION-LENGTH | | SESSION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | |
/ SESSION-DATA / / SESSION-DATA /
/ / / /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
SESSION-STATUS: A 4 bit field used in a response to indicate the SESSION-TYPE: A 16 bit field in network order giving the type of the
success (or otherwise) of an operation, as defined in the DNS
Session Signaling Status Codes Registry. It SHOULD contain
"NOERROR" (0) in a request message but the responder MUST NOT
reject the request if it does not.
SESSION-TYPE: A 12 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 SESSION-LENGTH: A 16 bit field in network order giving the size in
octets of SESSION-DATA. octets of SESSION-DATA.
SESSION-DATA: Type-code specific. The SESSION-DATA field MUST be SESSION-DATA: Type-code specific.
NUL padded to an even number of octets such that each Session
Signaling TLV is aligned on a two octet boundary relative to the
start of the first Session Signaling TLV. Padding octets MUST NOT
be included in the calculation of SESSION-LENGTH but MUST be
included in the calculation of the overall message length.
<< RB: the padding is specified such that client code can read the
type and length fields directly from an aligned uint16_t array (with
byte swapping) >>
4. Mandatory TLVs 4. Mandatory TLVs
4.1. Feature Negotiation 4.1. Session Management Support TLVs
4.1.1. TypeCode Support 4.1.1. "Not Implemented"
The TypeCode Support TLV (1) is used to allow a client and server to Since the "NOTIMP" RCODE is required to indicate lack of support for
exchange information about which Session Signaling Type Codes they the Session Signaling OpCode itself, the "Not Implemented" TLV (0)
support. MUST be returned in response to a TLV that is not implemented by the
responder.
The SESSION-DATA contains a list of the Session Signaling Type Codes This TLV has no SESSION-DATA.
supported by the sender.
1 1 1 1 1 1 4.2. Session Management TLVs
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| TYPE CODEs |
/ ... /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
TYPE CODEs: A list of 16 bit words in network order comprising the 4.2.1. Start Session
complete list of Session Signaling Type Codes supported by the
sender. Since a Session Signaling Type Code is in reality only a
12 bit value, the four most significant bits of each word MUST be
zero. The number of TYPE CODEs can be calculated from the total
length of the TLV.
An initiator MAY send its own list of supported Session Signaling The Start Session TLV (1) SHOULD be used by a client to indicate
Type Codes in a TypeCode Support TLV, and if sent they MUST be support for Session Signaling. It MUST NOT be initiated by a server.
complete. Otherwise the SESSION-DATA MUST be empty. In either case
the responder MUST respond with its complete list of supported Type
Codes.
4.2. Layer 4 Connection Management TLVs 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.
4.2.1. Terminate This TLV has no SESSION-DATA.
The Terminate TLV (64) MAY be sent by a server to request that the << RB: this could perhaps also be used as a real "no-op" message to
client terminate the session, and when sent MUST be the only TLV provide application-level keep-alive pings >>
present. It MUST NOT be requested by a client.
4.2.2. Terminate Session
The Terminate Session TLV (2) MAY be sent by a server to request that
the client terminate the session. It MUST NOT be initiated by a
client.
The client SHOULD terminate the session as soon as possible, but MAY The client SHOULD terminate the session as soon as possible, but MAY
wait for any inflight queries to be answered. It MUST NOT initiate wait for any inflight queries to be answered. It MUST NOT initiate
any new queries over the existing session, nor send any further TLVs any new requests over the existing session.
other than its response to the Terminate request.
<< RB: dns-sd push has a "reconnect delay" option but I think it's of The SESSION-DATA is as follows:
questionable value since in an anycast or load-balancing architecture
there's no way for the client to know which instance sent the option
nor control which server instance the next connection will go to.
This would IMHO be better controlled directly at the TCP layer. >>
4.2.2. Idle Timeout 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| RECONNECT DELAY |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
The Idle Timeout TLV (65) has similar semantics to the EDNS TCP RECONNECT DELAY: a time value, specified as a 16 bit word in network
Keepalive Option [RFC7828]. It is used by a server to tell the order in units of 100 milliseconds, within which the client MUST
client how long it may leave the current session idle for. NOT establish a new session to the current server.
The SESSION-DATA is as follows: The RECOMMENDED value is 10 seconds. << RB: text required here about
default values for load balancers, etc >>
4.2.3. Idle Timeout
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
it may leave the current session idle for. a client. The definition
of an idle session is as specified in [RFC7766].
Messages generate by the client have no SESSION-DATA (whether in
requests or responses). A client-initiated Idle Timeout TLV allows
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:
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 | | IDLE TIMEOUT |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
IDLE TIMEOUT: the idle timeout for the current session, specified as IDLE TIMEOUT: the idle timeout for the current session, specified as
a 16 bit word in network order in units of 100 milliseconds. a 16 bit word in network order in units of 100 milliseconds.
It is NOT an error for this TLV and the similar EDNS option to appear
within the same session. The client SHOULD pay attention to the most
recently received value, regardless of which method was used to send
it.
The client SHOULD terminate the current session if it remains idle The client SHOULD terminate the current session if it remains idle
for longer than the specified timeout (and MAY of course terminate for longer than the specified timeout (and MAY of course terminate
the session earlier). The server MAY unilaterally terminate the the session earlier). The server MAY unilaterally terminate the
connection at any time, but SHOULD allow the client to keep the connection at any time, but SHOULD allow the client to keep the
connection open if further messages are received before the idle connection open if further messages are received before the idle
timeout expires. timeout expires.
<< RB: this assumes that the EDNS OPT RR is added at the final stage A client / server pair that supports Session Signaling MUST NOT use
of message processing, and therefore not affected by out-of-order the EDNS TCP KeepAlive option within any message once bi-directional
processing - c.f. comment above about sequencing points >> 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 Status Codes Registry 5.2. DNS Session Signaling Type Codes Registry
IANA are directed to create the DNS Session Signaling Status Codes
Registry, with initial values as follows:
+------+----------+---------------------------------+-----------+
| Code | Mnemonic | Description | Reference |
+------+----------+---------------------------------+-----------+
| 0 | NOERROR | TLV processed successfully | RFC-TBD1 |
| | | | |
| 4 | NOTIMP | TLV not implemented | RFC-TBD1 |
| | | | |
| 5 | REFUSED | TLV declined for policy reasons | RFC-TBD1 |
+------+----------+---------------------------------+-----------+
Registration of additional Session Signaling Status Codes requires
Standards Action.
5.3. 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 | Reserved | | RFC-TBD1 | | 0 | Not implemented | | RFC-TBD1 |
| | | | | | | | | |
| 1 | TypeCode Support | Standard | RFC-TBD1 | | 1 | Start Session | Standard | RFC-TBD1 |
| | | | | | | | | |
| 2 - 63 | Unassigned, reserved for | | | | 2 | Terminate Session | Standard | RFC-TBD1 |
| | feature negotiation TLVs | | | | | | | |
| | | | | | 3 | Idle Timeout | Standard | RFC-TBD1 |
| 64 | Terminate | Standard | RFC-TBD1 | | | | | |
| | | | | | 4 - 63 | Unassigned, reserved for | | |
| 65 | Idle Timeout | Standard | RFC-TBD1 | | | session management TLVs | | |
| | | | | | | | | |
| 66 - 127 | Unassigned, reserved for | | | | 64 - | Unassigned | | |
| | session management TLVs | | | | 63487 | | | |
| | | | | | | | | |
| 127 - | Unassigned | | | | 63488 - | Reserved for local / | | |
| 3965 | | | | | 64511 | experimental use | | |
| | | | | | | | | |
| 3968 - | Reserved for local / | | | | 64512 - | Reserved for future expansion | | |
| 4031 | experimental use | | | | 65535 | | | |
| | | | | +-----------+--------------------------------+----------+-----------+
| 4032 - | Reserved for future expansion | | |
| 4095 | | | |
+----------+---------------------------------+----------+-----------+
Registration of additional Session Signaling Type Codes requires Registration of additional Session Signaling Type Codes requires
Expert Review. << RB: definition of process required? >> Expert Review. << RB: definition of process required? >>
6. Security Considerations 6. Security Considerations
The authors are not aware of any specific security considerations If this mechanism is to be used with DNS over TLS, then these
introduced by this specification at this time. messages are subject to the same constraints as any other DNS over
TLS messages and MUST NOT be sent in the clear before the TLS session
is established.
7. Acknowledgements 7. Acknowledgements
TBW TBW
8. Normative References 8. References
8.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/
RFC6891, April 2013, RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>. <http://www.rfc-editor.org/info/rfc6891>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<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>.
Authors' Addresses 8.2. Informative References
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <http://www.rfc-editor.org/info/rfc7858>.
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
skipping to change at page 10, line 4 skipping to change at page 10, line 28
Phone: +1 408 974 3207 Phone: +1 408 974 3207
Email: cheshire@apple.com Email: cheshire@apple.com
John Dickinson John Dickinson
Sinodun Internet Technologies Sinodun Internet Technologies
Magadalen Centre Magadalen Centre
Oxford Science Park Oxford Science Park
Oxford OX4 4GA Oxford OX4 4GA
United Kingdom United Kingdom
Email: jad@sinodun.com
Sara Dickinson
Sinodun Internet Technologies
Magadalen Centre
Oxford Science Park
Oxford OX4 4GA
United Kingdom
Email: sara@sinodun.com
Allison Mankin Allison Mankin
Unaffiliated Salesforce
Email: allison.mankin@gmail.com Email: allison.mankin@gmail.com
Tom Pusateri Tom Pusateri
Unaffiliated Unaffiliated
Phone: +1 843 473 7394 Phone: +1 843 473 7394
Email: pusateri@bangj.com Email: pusateri@bangj.com
 End of changes. 53 change blocks. 
171 lines changed or deleted 214 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/