One document matched: draft-baker-v6ops-session-start-time-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
                                 otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a 
                                 string such as <29> printed in the blank line at the 
                                 beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.  
         Note the ToC may be omitted for very short documents,but idnits insists on a ToC 
         if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references. 
         Some like symbolic tags in the references (and citations) and others prefer 
         numbers. The RFC Editor always uses symbolic tags.
         The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
                                 This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each 
         main section on a new page but does not omit the blank lines between list items. 
         If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="info" docName="draft-baker-v6ops-session-start-time-00"
     ipr="trust200902">
  <front>
    <title abbrev="It takes too long...">Opening TCP Sessions in Complex
    Environments</title>
    <author fullname="Fred Baker" initials="F.J." surname="Baker">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street></street>
          <city>Santa Barbara</city>
          <code>93117</code>
          <region>California</region>
          <country>USA</country>
        </postal>
        <email>fred@cisco.com</email>
      </address>
    </author>
    <date year="2010" />
    <area>Operations and Management</area>
    <workgroup>IPv6 Operations</workgroup>
    <abstract>
      <t>A barrier to the deployment of IPv6 is the amount of time it takes to
      open a session using common transport APIs. This note addresses issues
      and requests solutions that may respond to them.</t>
    </abstract>
    <!--		
		<note title="Foreword">
		</note>
		-->
    <!--
    <note title="Requirements">
      <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"></xref>.</t>
    </note>
    -->
    <!--
            <?rfc needLines="10" ?>
            <texttable anchor="table_example" title="A Very Simple Table">
                <preamble>Tables use ttcol to define column headers and widths.
                Every cell then has a "c" element for its content.</preamble>
 <ttcol align="center">ttcol #1</ttcol>
                    <ttcol align="center">ttcol #2</ttcol>
                      <c>c #1</c>		<c>c #2</c>
                      <c>c #3</c>		<c>c #4</c>
                      <c>c #5</c>		<c>c #6</c>
                <postamble>which is a very simple example.</postamble>
            </texttable>
    -->
  </front>
  <middle>
    <!--		
			<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
			<t>
				<list style="symbols">
					<t>First bullet</t>
					<t>Second bullet</t>
				</list>
			</t>
-->
    <!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
	ASCII artwork goes here... 
]]>
</artwork>
</figure>
-->
    <section title="Introduction">
      <t>One of the issues in IPv6 deployment is the time, from a user's
      perspective, that it takes to open a standard application, which is to
      say the time it takes to open a TCP session that the application can use
      to accomplish its mission.</t>
      <t>One thing to understand is that each source/destination pair of
      addresses (IPv4 and IPv6 addresses, including link-local, organizational
      scope such as <xref target="RFC1918"></xref> or <xref
      target="RFC4193">ULA</xref>, and global addresses) defines a path
      between those interfaces. The path may or may not actually work (the two
      addresses may not be in the same domain or the same scope, or routing
      may not be defined, or forwarding may be filtered), and even if the
      network workds, the peer may or may not be willing to respond to any
      given address. Hence, in the worst case, every pair of addresses may
      need to be tried in the process of finding a pair that enables
      communication.</t>
      <t>In the immortal words of <xref target="RFC1958"></xref>, <list
          style="empty">
          <t>The current exponential growth of the network seems to show that
          connectivity is its own reward, and is more valuable than any
          individual application such as mail or the World-Wide Web. This
          connectivity requires technical cooperation between service
          providers, and flourishes in the increasingly liberal and
          competitive commercial telecommunications environment.</t>
        </list></t>
      <t>An application or API that fails to quickly enable connectivity
      between any two systems that are authorized to communication. has
      fundamentally missed the point, and can expect its customers to migrate
      to solutions that don't miss the point.</t>
      <t>Part of the issue has to do with source address choice in multihomed
      networks, as described in <xref
      target="I-D.troan-multihoming-without-nat66"></xref>; if the host
      selects the wrong source address for a session with a peer, <xref
      target="RFC2827">BCP 38</xref> ingress filtering will prevent its
      delivery. Any delay in selecting an alternative source address will
      irritate the user, making IPv6 appear less desirable.</t>
      <t>Part of it has to do with the standard response of TCP and SCTP
      clients to RST and ICMP Unreachable messages; if another address pair
      exists, any delay in selecting an alternative source address will
      irritate the user, making IPv6 appear less desirable.</t>
      <t>Part of it has to do with the rate of session attempts; if one takes
      multiple seconds per attempt and, present implementations require as
      much as 40 seconds to open a basic web page. Again, such delays irritate
      the user, making IPv6 appear less desirable.</t>
    </section>
    <section title="Possible Solutions">
      <t>TCP's standard reaction to soft errors, which includes its response
      to an abrupt RST from the peer and its response to ICMP "unreachable
      messages", doesn't help. <xref target="RFC5461"></xref> makes pragmatic
      suggestions to address the issues. From an operator's perspective, it is
      felt that the fundamental suggestion is a good one, and either should be
      standardized and widely deployed or a better suggestion should be
      standardized and widely deployed.</t>
      <t>The <xref target="I-D.wing-http-new-tech">Happy Eyeballs</xref> draft
      addresses the startup question. From an operator's perspective, it is
      felt that the fundamental suggestion is a good one, and either should be
      standardized and widely deployed or a better suggestion should be
      standardized and widely deployed.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>This memo asks the IANA for no new parameters.</t>
      <t>Note to RFC Editor: This section will have served its purpose if it
      correctly tells IANA that no new assignments or registries are required,
      or if those assignments or registries are created during the RFC
      publication process. From the author"s perspective, it may therefore be
      removed upon publication as an RFC at the RFC Editor"s discretion.</t>
    </section>
    <section anchor="Security" title="Security Considerations">
      <t>This note doesn't address security-related issues.</t>
    </section>
    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This note was discussed with Joel Jaeggli, Dan Wing, and Fernando Gont.</t>
    </section>
    <section anchor="log" title="Change Log">
      <t><list style="hanging">
          <t hangText="Initial Version:">October 6, 2010</t>
        </list></t>
    </section>
  </middle>
  <back>
    <!-- references split to informative and normative -->
    <references title="Informative References">
      <?rfc include="reference.RFC.2827" ?>
      <?rfc include="reference.I-D.wing-http-new-tech"?>
      <?rfc include="reference.I-D.troan-multihoming-without-nat66" ?>
      <?rfc include="reference.RFC.1918" ?>
      <?rfc include="reference.RFC.1958" ?>
      <?rfc include="reference.RFC.4193" ?>
      <?rfc include="reference.RFC.5461" ?>
    </references>
  </back>
</rfc>