One document matched: draft-baker-6man-multi-homed-host-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="std" docName="draft-baker-6man-multi-homed-host-00"
     ipr="trust200902">
  <front>
    <title abbrev="Host routing in a multi-prefix network">Host routing in a
    multi-prefix network</title>

    <author fullname="Fred Baker" initials="F.J." surname="Baker">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street/>

          <city>Santa Barbara</city>

          <code>93117</code>

          <region>California</region>

          <country>USA</country>
        </postal>

        <email>fred@cisco.com</email>
      </address>
    </author>

    <author fullname="Brian Carpenter" initials="B. E." surname="Carpenter">
      <organization abbrev="Univ. of Auckland"/>

      <address>
        <postal>
          <street>Department of Computer Science</street>

          <street>University of Auckland</street>

          <street>PB 92019</street>

          <city>Auckland</city>

          <region/>

          <code>1142</code>

          <country>New Zealand</country>
        </postal>

        <email>brian.e.carpenter@gmail.com</email>
      </address>
    </author>

    <date/>

    <area>Internet Engineering Task Force</area>

    <workgroup/>

    <abstract>
      <t>This note describes expected host behavior in a network that has more
      than one prefix, each allocated by an upstream network that implements
      BCP 38 filtering.</t>
    </abstract>

    <!--
		<note title="Foreword">
		</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 anchor="intro" title="Introduction">
      <t>This note describes the expected behavior of an <xref
      target="RFC2460">IPv6</xref> host in a network that has more than one
      prefix, each allocated by an upstream network that implements <xref
      target="RFC2827">BCP 38</xref> filtering. It expects that the network
      will implement some form of egress routing, so that packets sent to a
      host outside the local network from a given ISP's prefix will go to that
      ISP. If the packet is sent to the wrong egress, it is liable to be
      discarded by the BCP 38 filter. However, the mechanics of egress routing
      once the packet leaves the host are out of scope. The question here is
      how the host interacts with that network.</t>

      <section title="Requirements Language">
        <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>

    <section anchor="host_expects"
             title="Expectations the host has of the network">
      <t>A host receives on-link prefixes in a <xref target="RFC4861">Router
      Advertisement</xref>, which goes on to identify preference order among
      them and whether they are usable by <xref target="RFC4862">SLAAC</xref>
      <xref target="RFC4941"/> <xref target="RFC7217"/>, or whether they must
      be assigned using <xref target="RFC3315">DHCPv6</xref>.</t>

      <t>The simplest multihomed network implementation might be a LAN with
      one or more hosts on it and two or more routers, one for each upstream
      network. In such a network, there is no routing protocol, and the two
      routers may not even know that the other is a router as opposed to a
      host, apart from the fact that it is emitting Router Advertisements
      (RAs). One might expect that the routers may or may not receive each
      other's RAs and form an address in the other router's prefix. However,
      all hosts in such a network might be expected to create an address in
      each prefix so advertised.</t>

      <t>Because there is no routing protocol among those routers, there is no
      mechanism by which packets can be deterministically forwarded between
      the routers (as described in <xref target="RFC3704">BCP 84</xref>) in
      order to avoid BCP 38 filters. Even if there was, it would be an
      indirect route, rather than a direct route originating with the host.
      Therefore the host needs to select the appropriate router itself.</t>

      <t>Since the host derives fundamental default routing information from
      the RA, this implies that, on any network with multiple prefixes, each
      prefix SHOULD be advertised by one of the attached routers, even if
      addresses are being assigned using DHCPv6.</t>
    </section>

    <section anchor="network_expects"
             title="Reasonable expectations of the host">
      <t>Modern hosts maintain a fair bit of history, in terms of what has
      historically worked or not worked for a given address or prefix and in
      some cases the effective window and MSS values for TCP. This includes a
      next hop address for use when a packet is sent to the indicated
      address.</t>

      <t>A host SHOULD include the prefix it used in a successful exchange
      with a remote address or prefix in such history. On subsequent attempts
      to communicate with that remote address, if it has such an address at
      that time, a host MAY use its address in the remembered prefix for the
      exchange.</t>

      <t>A host SHOULD select a "default gateway" for each prefix it uses to
      obtain one of its own addresses. That router SHOULD be one of the
      routers advertising the prefix in its RA. As a result of doing so, when
      a host emits a datagram using a source address in one of those prefixes
      and has no history directing it otherwise, it SHOULD send it to the
      indicated "default gateway". In the "simplest" network described in
      <xref target="host_expects"/>, that would get it to the only router that
      is capable of getting it to the right ISP. This will also apply in more
      complex networks, even when more than one physical or virtual interface
      is involved.</t>

      <t>There is an interaction with <xref target="RFC6724">Default Address
      Selection</xref>. Rule 5.5 of that specification states that the source
      address used to send to a given destination address should if possible
      be chosen from a prefix known to be advertised by the next-hop router
      for that destination. This selection rule would be applicable in a host
      following the recommendation in the previous paragraph.</t>
    </section>

    <section title="Expectations of multihomed networks">
      <t>The direct implication of <xref target="host_expects"/> is that
      routing protocols used in multihomed networks SHOULD be capable of
      source-prefix based egress routing, and that multihomed networks SHOULD
      deploy them.</t>
    </section>

    <section title="Residual issues">
      <t>The assumption that packets will be forwarded to the appropriate
      egress by the local routing system might cause at least one extra hop in
      the local network (from the host to the wrong router, and from there to
      another router on the same LAN but in a different subnet). In some
      scenarios, where the local network is a highly constrained or lossy
      wireless network, this extra hop may be a significant performance
      handicap.  </t>

      <t>In a slightly more complex situation, which happens to be one of the
      authors' home plus corporate home-office configuration, the two upstream
      routers might be on different LANs and therefore different subnets
      (e.g., the host is itself multi-homed). In that case, there is no way
      for the "wrong" router to detect the existence of the "right" router, or
      to route to it.</t>

      <t>In such a case it is particularly important that hosts take the
      responsibility to memorize and select the best first-hop as described in
      <xref target="network_expects"/>.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo asks the IANA for no new parameters.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document does not create any new security or privacy
      exposures.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t/>
    </section>
  </middle>

  <back>
    <!-- references split to informative and normative -->

    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.2460"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.2827" ?>

      <?rfc include="reference.RFC.3315" ?>

      <?rfc include="reference.RFC.3704" ?>

      <?rfc include="reference.RFC.4861" ?>

      <?rfc include="reference.RFC.4862" ?>

      <?rfc include="reference.RFC.4941" ?>

      <?rfc include="reference.RFC.6724" ?>

      <?rfc include="reference.RFC.7217" ?>
    </references>

    <section anchor="log" title="Change Log">
      <t><list style="hanging">
          <t hangText="Initial Version:">date</t>
        </list></t>
    </section>
  </back>
</rfc>