One document matched: draft-howard-homenet-routing-requirements-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<rfc category="info" docName="draft-howard-homenet-routing-requirements-00"
     ipr="trust200902" submissionType="IETF" xml:lang="en">
  <!--				 category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="homenet-routing-reqs">Homenet Routing Requirements</title>

    <author fullname="Lee Howard" initials="L" surname="Howard">
      <organization>Time Warner Cable</organization>

      <address>
        <postal>
          <street>13820 Sunrise Valley Drive</street>

          <!-- Reorder these if your country does things differently -->

          <city>Herndon</city>

          <region>VA</region>

          <code>20171</code>

          <country>US</country>
        </postal>

        <phone>+1 703 345 3513</phone>

        <email>lee.howard@twcable.com</email>
      </address>
    </author>

    <date month="December" year="2011" />

    <!-- Meta-data Declarations -->

    <area>Internet</area>

    <workgroup></workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>UP prefix information</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This document describes the requirements for routing in an unmanaged
      home network.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>This document describes the requirements for routing in an unmanaged
      home network. Home networks are evolving to include multiple routers and
      potentially multiple possible exits. These exist may include multiple
      Internet access paths (through one or more multiple access providers),
      "walled garden" environments for video, VPN, or other service access,
      and smart energy devices.</t>
    </section>

    <section title="Requirements" toc="default">
      <t><list counter="REQ">
          <t>Reachability between all nodes in the home network. Links may be
          Ethernet, WiFi, MoCA, or any other; test all solutions against
          mutliple L2 types.</t>

          <t>Border detection. Any solution will have to determine the routing
          boundary. It is assumed that no home networking device can handle a
          full routing table for the Internet, and that a home router should
          not be required to do so.<list>
              <t>Border may be upstream ISP, or may be a device that is a
              gateway to SmartGrid devices, e.g. a controller that speaks RPL
              to 802.15.4 and foo to home net. Or there may be no border, if
              no external connection has been established.</t>

              <t>Must be able to find “up” (a path to the
              Internet), but must not be dependent on “up”
              (Internet connectivity) existing for intra-home
              reachability.</t>

              <t>May be discovered by routing protocol, or other means.</t>
            </list></t>

          <t>Robust to routers being moved/added/removed/renumbered.
          Convergence time a few minutes or less.</t>

          <t>No configuration required. It may be acceptable to require a
          single password or passphrase to be entered on each device, both for
          security, and to establish the administrative boundary.</t>

          <t>Best-path is a non-requirement.</t>

          <t>Support for multiple upstream networks is a requirement.<list>
              <t>Including wireless offload, video-only, and split-tunnel VPN
              scenarios.</t>

              <t>It may be assumed that each upstream will be connected via a
              separate router, not multihomed off the same router.</t>

              <t>Must support a prefix delegated from each provider. How hosts
              handle multiple prefixes is not a routing problem.</t>

              <t>Load-balancing among providers is a non-requirement.</t>

              <t>If multiple upstream networks can provide a path to the same
              destination (such as an Internet host), the solution must allow
              for backup in case the router or link to one upstream fails.
              Failover time should be within a few minutes.</t>

              <t>Must support a "walled-garden" network. This might routing
              based on either source address (from the walled garden network)
              or destination address (to the walled garden network); support
              for both is not required.</t>

              <t>Source address selection is out of scope for the routing
              solution. Choosing which address to use to look up the
              destination address is out of scope for the routing
              solution.</t>
            </list></t>

          <t>Cannot assume hierarchical prefix delegation in the home, unless
          the Homenet working group finds consensus on a hierarchical
          addressing mechanism.</t>

          <t>A host with mutliple upstream paths to the same destination
          (in-home or external) should be able to use another in case on
          fails.</t>

          <t>Prevent looping.</t>

          <t>Should be a lightweight solution.</t>

          <t>Must handle multi-dwelling units or other potential dense
          wireless or wired networks.</t>

          <t>Must be resilient to running on wireless networks. Must be able
          to handle both wired and wireless links.</t>

          <t>Robustness in the face of unintentional joining of networks.</t>
        </list></t>
    </section>

    <section title="Security Considerations">
      <t>As a requirements document, no security considerations are created.
      The solution should be safe from route injection to perpetrate
      man-in-the-middle attacks, especially in multi-dwelling or other
      dense/mesh networks, but this may be a link requirement more than a
      routing requirement.</t>
    </section>

    <section title="IANA Considerations">
      <t>There are no IANA considerations or implications that arise from this
      document.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Informative References">
      <reference anchor="RFC6204">
        <front>
          <title>Basic Requirements for IPv6 Customer Edge Routers</title>

          <author fullname="H. Singh">
            <organization>Cisco Systems, Inc.</organization>
          </author>

          <author fullname="W. Beebee">
            <organization>Cisco Systems, Inc.</organization>
          </author>

          <author fullname="C. Donley">
            <organization>CableLabs</organization>
          </author>

          <author fullname="B. Stark">
            <organization>AT&T</organization>
          </author>

          <author fullname="O. Troan" role="editor">
            <organization>Cisco Systems, Inc.</organization>
          </author>

          <date />
        </front>
      </reference>
    </references>
  </back>
</rfc>