One document matched: draft-bellis-dnsop-connection-close-00.xml

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc category="std" ipr="trust200902" updates="6891"
    docName="draft-bellis-dnsop-connection-close-00">
    <?rfc strict="yes" ?>
    <?rfc toc="yes" ?>
    <?rfc tocompact="no" ?>
    <?rfc compact="yes" ?>
    <?rfc subcompact="yes" ?>
    <?rfc sortrefs="yes" ?>
    <?rfc symrefs="yes" ?>
    <front>
        <title>Connection Close Signalling for DNS</title>
        <author initials="R.P." surname="Bellis" fullname="Ray Bellis">
            <organization>Nominet UK</organization>
            <address>
            <postal>
                <street>Minerva House</street>       
                <street>Edmund Halley Road</street>
                <street>Oxford Science Park</street>
                <city>Oxford</city>
                <code>OX4 4DQ</code>
                <country>United Kingdom</country>
            </postal>
            <phone>+44 1865 332211</phone>
            <email>ray.bellis@nominet.org.uk</email>
            <uri>http://www.nominet.org.uk/</uri>
        </address>
        </author>

        <date year="2014" month="October"/>
        <area>Operations Area</area>
        <workgroup/>
        <keyword/>

        <abstract>
            <t> This document updates <xref target="RFC6891"/> by specifying a new single-bit flag
                in a DNS response that when seen in a packet carried over a connection-orientated
                transport protocol indicates to the client that it should close the current
                connection.</t>
        </abstract>
    </front>

    <middle>
        <section anchor="intro" title="Introduction">
            <t> The DNS protocol <xref target="RFC1035"/> supports use of persistent TCP
                connections, although guidance as to when a connection should be terminated (and by
                which party) is limited <xref target="RFC5966"/>.</t>

            <t> This document updates the Extension Mechanisms for DNS (EDNS(0)) <xref
                    target="RFC6891"/> by specifying a new single-bit flag in a DNS response that
                when seen in a packet carried over a connection-orientated transport protocol
                indicates to the client that it should close the current connection.</t>

            <t> Having the client close the connection reduces the amount of TCP state information
                that must be stored by the server compared to that resulting from the server
                initiating a unilateral close itself. </t>

            <t> TODO: does it make sense to specify a request side meaning for this flag, indicating
                that the server may half-close its "read" side of the connection? This would make
                the semantics even closer to those of the HTTP/1.1 "Connection: close" header (see
                Section 14.10 of <xref target="RFC2616"/>)</t>

        </section>

        <section anchor="terminology" title="Terminology">
            <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
                "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
                interpreted as described in <xref target="RFC2119"/>. </t>
        </section>

        <section anchor="specification" title="Specification">

            <t> The "Connection Close" (CC) bit is held in the third-most signifiant bit of the
                third byte of the "extended RCODE and flags" portion of an EDNS(0) OPT meta-RR:</t>

            <figure>
                <artwork><![CDATA[ 
                     +0 (MSB)              +1 (LSB)
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       0: |    EXTENDED-RCODE     |        VERSION        |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       2: |DO| Z|CC|                  Z                   |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 ]]></artwork>
            </figure>

            <t> Note to RFC editor: replace the first 'Z' in the figure above with 'TO' if
                draft-hzhwm-dprive-start-tls-for-dns is published as an RFC before this
                specification.</t>

        </section>

        <section anchor="behaviour" title="Connection Handling">

            <section anchor="servers" title="Servers">

                <t> Servers MAY set this flag to indicate that further queries received over the
                    current connection should not be sent.</t>

                <t> An incompatible client will not understand this flag and may continue sending
                    requests and therefore the server MUST NOT refuse to service subsequent
                    requests. The server MAY unilaterally close idle connections regardless, per
                        <xref target="RFC5966"/> and Section 4.2.2 of <xref target="RFC1035"/></t>

                <t> Since this flag requires EDNS(0) support, note that this flag cannot be set
                    unless the client has indicated support for EDNS(0) by sending an OPT meta-RR
                    itself, per Section 7 of <xref target="RFC6891"/></t>

                <t> TODO: note - the constraint in RFC 6891 appears unnecessarily strict - it
                    appears to mandate that the EDNS(0) support indication is on a per-request
                    basis, but it would be reasonable on a connection-orientated transport to assume
                    that ANY preceding request on that connection with an OPT RR is sufficient to
                    indicate that the client supports EDNS(0).</t>

                <t> TODO: if a request-side semantic is defined for this flag, what are the TCP
                    state-maintenance implications if the server performs a 'shutdown(fd, SHUT_RD)'?
                </t>
            </section>

            <section anchor="clients" title="Clients">
                <t> Clients receiving a packet with this flag set MUST NOT send any further queries
                    over the current connection and MUST initiate closure of that connection.</t>

                <t> TODO: what are the TCP state-maintenance implications if the client performs a
                    'shutdown(fd, SHUT_WR)'?</t>
            </section>

        </section>

        <section anchor="security" title="Security Considerations">
            <t> None identified (yet). </t>
        </section>

        <section anchor="iana" title="IANA Considerations">
            <t> IANA are requested to update the EDNS Header Flag Registry according to <xref
                    target="specification"/>.</t>
            
            <t> Note to IANA and RFC Editor: The actual bit assigned will depend on whether any
                other document specifies a used for the above-specificed bit in advance of
                publication of this document as an RFC.</t>
        </section>

        <!-- <section title="Acknowledgements"> </section> -->

    </middle>

    <back>
        <references title="Normative References">
            <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml"?>
            <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
            <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5966.xml"?>
            <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6891.xml"?>
        </references>

        <references title="Informative References">
            <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml"?>
        </references>

        <section title="Change Log" anchor="changelog">

            <t>Note to RFC editor: remove this section before publication.</t>

            <t>draft-bellis-dnsop-connection-close-00<list>
                    <t>Initial draft</t>
                </list>
            </t>
        </section>

    </back>
</rfc>